Skip to content
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

TTFX, PrecomopileTools, Loading time #225

Open
hhaensel opened this issue Sep 23, 2023 · 7 comments
Open

TTFX, PrecomopileTools, Loading time #225

hhaensel opened this issue Sep 23, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@hhaensel
Copy link
Member

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)
@essenciary
Copy link
Member

essenciary commented Sep 23, 2023

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

@PingoLee
Copy link

I think if this works with @page in modules that are more complex, question 3 is negligible. The reduction of memory allocation is amazing!

@PGimenez PGimenez added the enhancement New feature or request label Sep 27, 2023
@PGimenez
Copy link
Member

PGimenez commented Nov 1, 2023

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

@essenciary
Copy link
Member

@PGimenez Where is the code for the package version of the app?

@PGimenez
Copy link
Member

PGimenez commented Nov 2, 2023

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

@hhaensel
Copy link
Member Author

hhaensel commented Mar 4, 2024

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"

@yakir12
Copy link
Contributor

yakir12 commented May 17, 2024

So where does this stand right now? I'm also running into similar issues with fly...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants