GenieFramework / Stipple.jl

The reactive UI library for interactive data applications with pure Julia.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

TTFX, PrecomopileTools, Loading time

hhaensel opened this issue · comments

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.

image

@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...