Stipple.jl
Stipple.jl copied to clipboard
TTFX, PrecomopileTools, Loading time
The current load process of an App is done internally by Revise.includet()
.
This doesn't take advantage of the fact that the App is typically a module (not necessarily, though) and could be precompiled.
Alternatively one could load the App with a using statement, which speeds up loading drastically and even more when using PrecompileTools. There are some pitfalls with this approach, but I'd like to discuss what could be the best approach.
Here's my MWE
module MyApp.jl
module MyApp
using PrecompileTools
using GenieFramework
@app HH begin
@in x = 10
@out y = 11
end
ui() = [
row(cell(class = "st-module", row([
h3("Hello")
numberfield("x", :x)
])))
]
# any definition that sets up runtime variables needs to go into the `__init__` function.
# That's in any case the page or route command. But also any global variable, e.g. a DataFrame that is loaded at the beginning
# needs to go here.
function __init__()
route("/") do
model = init(HH) |> handlers
page(model, ui) |> html
end
end
# include typical calls in the section below
# The `Timer()` command in Stipple.jl had to be escaped during precompilation, because the process wouldn't stop otherwise.
@compile_workload begin
Stipple.PRECOMPILE[] = true
ui()
init(HH)
Stipple.PRECOMPILE[] = false
end
end
classical bootstrap.jl
using Revise
Revise.includet("MyApp.jl")
alternative bootstrap.jl
pushfirst!(LOAD_PATH, ".")
using MyApp
Testing
using GenieFramework
@time begin Genie.loadapp(); MyApp.ui(); init(MyApp.HH) end
Result is
- classical:
4.626385 seconds (2.23 M allocations: 151.089 MiB, 95.21% compilation time: <1% of which was recompilation
- alternative:
0.351679 seconds (58.67 k allocations: 3.758 MiB, 20.45% compilation time)
@hhaensel this is amazing in terms of startup time. I need to run the code and check. Things that come to mind and I'll be looking for: 1/ does it break hot code load/reload features 2/ will @page work inside init 3/ can we make the user facing API nicer (eg by using some macros to hide some of these complexities)
I think if this works with @page in modules that are more complex, question 3 is negligible. The reduction of memory allocation is amazing!
I tried setting up this app as a package and loading it with using
and indeed there's a remarkable speedup and reduction in memory allocation after the first precompilation. I also added PrecompileTools but it only shaved off .3 seconds (I'm surely not using it right)
Loading the app the usual way
❯ julia --project -e '@time begin using GenieFramework; Genie.loadapp();up();end'
┌ Info: 2023-11-01 14:35:55
└ Web Server starting at http://127.0.0.1:8000
15.784171 seconds (15.93 M allocations: 1.027 GiB, 4.83% gc time, 64.93% compilation time: 9% of which was recompilation)[ Info: 2023-11-01 14:35:55 Listening on: 127.0.0.1:8000, thread id: 1
Loading the app as a package
❯ julia --project -e "@time begin using Gallery; Gallery.up();end"
┌ Info:
└ Web Server starting at http://127.0.0.1:8000
3.786981 seconds (3.52 M allocations: 211.670 MiB, 6.69% gc time, 1.76% compilation time: 57% of which was recompilation)[ Info: Listening on: 127.0.0.1:8000, thread id: 1
Still, the app doesn't really work when loaded as a package. User-defined routes with @page
aren't registered and return a 404.
@PGimenez Where is the code for the package version of the app?
@PGimenez Where is the code for the package version of the app?
I ended up trying with the BERT demo since the Gallery one wasn't fully working. Probably due to the way I'm including all the various components.
The code is here. All I did was move to a Pkg structure, replace app.jl with Bert.jl, and declare the root path inside the __init__
function. It all works fine.
If we agree to my latest Genie PR we can simplify loading of local modules via.
@using StippleTTFX
@using temp/StippleTTFX2
@using temp\StippleTTFX2
@using "C:/temp with space and colon/StippleTTFX2"
So where does this stand right now? I'm also running into similar issues with fly...