-
-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TTFW: Blink.Window() just takes too long to load #288
Comments
Wow, maybe a PR would be ideal to discuss, wouldn't it? I fully agree, now that Julia 1.7 is so mach snappier, the not-so-optimised packages shine through. I also need to revisit my packages, they started to feel quite slow 😆 |
Except that it has to be 2 PRs and I didn't realise this was the case when I first made this issue. But yes I can do a PR for both, as mentioned in the WebIO.jl issue. One thing that may be contentious is depending on Mux.jl in WebIO.jl, instead of putting it in Requires.jl. Otherwise things are a litte more complicated. |
PR is in JuliaGizmos/WebIO.jl#478 |
So I use blink for a lot of things, and it's useful. But its tedious.
using Blink
takes over 5 seconds on my laptop:Mostly this is spent in AssetRegistry.jl (the large red section). I'm not sure why this takes so long.
Second, the first time
Blink.Window()
takes over 11 seconds:A lot of compilation (cant we
precompile
some of this for a genericWindow
call?) and the large middle chunk in Mux.jl and Parser, wherever that is.Loading vscode only takes 2 seconds, and it's built on Electron too...
How do we reduce this to a reasonable amount?
Edit:
Package load time
It seems at least partly this is caused by the strange relationships of Blink.jl and WebIO.jl: If Blink depends on WebIO.jl, why is there code for blink in a Requires.jl block in WebIO.jl? This breaks precompilation.
Reorganising the requires block in WebIO.jl gets the load time of Blink.jl down to 1 second!
Blink.Window
A large fraction of the load time is parsing in s
JSON.Parser.parse
. For a generic window, surely we can do this work up-front during precompilation?Another large fraction of the work is type inference, probably due to all the untyped objects. This also means that
precompile(Window, ())
is not very successful. Precompiling the component methods thatWindow()
ends up calling in HTTP.jl/Mux.jl may be able to reduce this. But more type stability should also help.The text was updated successfully, but these errors were encountered: