Release v1

[asinghvi17]

@KristofferC @SimonDanisch is there a release schedule for the new version of PackageCompiler?

[KristofferC]

I thought it could hang on master for a while to get people a chance to properly test it out. I don't see a reason not to release it though. No really known bugs (that is caused by PackageCompiler itself and are not upstream bugs) so I feel it is in a pretty decent shape.

[DilumAluthge]

It would be great to get a release out soon.

That being said, it would be ideal to fix #317 before making a release.

[DilumAluthge]

@KristofferC Now that you’ve fixed #317, let’s make a release?

[KristofferC]

Yeah, I should write something short about the API being changed and how to use the old version if needed. I should also write a release post for discourse probably

[KristofferC]

Let's release then?

[hhaensel]

I followed the instructions of the Plots example and successfully compiled a dll on windows. However, when I use this dll in Atom/Juno all plots take approx. 2 seconds to display, while they display immediately with the default system image. (@time always gives <0.1s, so the problem is linked to atom. From a normal REPL, plotting is fast as usal).
I think that Gtk.jl is not involved in this delay. At least I don't receive compiler warnings. Any idea, why this is happening?
Otherwise: the new version is a great achievement, congratulations!

EDIT:
Windows 10, 64-bit
Atom 1.44.0

[KristofferC]

You, mean that every plot is delayed in Juno? I tried it myself on a Mac and could not observe this happening.

[pfitzseb]

HTML plots (e.g. with the plotly or plotlyjs backends) were pretty slow in Juno <0.12.1 (runtime, not compilation time). You could try with a different backend (e.g. GR) and/or upgrade Juno.

Edit: Oh, and the runtime overhead was in the display method, which isn't benchmarked by @time.

[DilumAluthge]

Is this slowness still present if you use the REPL (instead of Atom/Juno)?

[hhaensel]

Thank you for answering so fast!
From the standalone REPL all is fine. Slowness only occurs if I use the newly compiled sysimage from the REPL within Atom/Juno or by executing a line in a file. If I start julia without --sysimage parameter from Atom/Juno all is fine as well.
I might be able to check on a different Windows PC tonight.

[DilumAluthge]

Perhaps it’s because Juno loads some of its own Julia packages that are invalidating some of the code in your sysimage.

If that is the case, then once Juno switches to vendoring all of their dependencies, then (if I understand correctly) the problem should be solved.

Either way, can you open a separate issue on this repo to track this problem? I don’t think this problem is blocking the release of 1.0.

[KristofferC]

Perhaps it’s because Juno loads some of its own Julia packages that are invalidating some of the code in your sysimage.

This does lead to some slowdown for the first call but it shouldn't affect future calls.

[hhaensel]

Reproducible on a second Windows 10 machine.
It is slow every! call.
Note that the timing results are very normal in both cases!
for sys.dll:

julia> @time plot(rand(5),rand(5))
  0.001199 seconds (2.02 k allocations: 137.789 KiB)

for plots.dll

julia> @time plot(rand(5),rand(5))
  0.001240 seconds (2.11 k allocations: 140.695 KiB)

It is just a 2 seconds delay between execution and display.

[hhaensel]

I also wouldn't judge this bocking. If I don't find a clue, I will open another issue. Thanks for your comments anyhow!

[KristofferC]

You could profile

p = plot(rand(5), rand(5)); @profile display(p)

[hhaensel]

Well, this did not change the behaviour and I must admit that I'm not that kind of an expert to understand how I could use this for further debugging :-(
What I did find out, though, is that calling

p = plot(rand(5), rand(5)); display(p)

displays the plot immediately but takes the 2 seconds to respond at the terminal. Similar, if I do

p = plot(rand(5), rand(5)); display(p);

nothing is displayed (as expected) but it takes 2 seconds until the terminal prompt is back.

[KristofferC]

Released