So much work has been done to improve julia compilation and remove invalidations. Things really feel a lot snappier to use. But there is still the problem of packages that were written without much thought to startup time, and TTFX - the time-to-first whatever a package does most, is sometimes real…

@PetrKryslUCSD im using TTFX like time-to-first-plot. The time to load a package + the time to do its main thing X that it does, using @time thefunction(x). My PR above made blinks load in 1s, but Window() takes 15 so its still not a huge gain.

Yeah SnoopCompile is more complicated. I mostly just use ProfileView.jl and Cthulhu.jl and give up after that. Anything really bad is pretty obvious in ProfileView. But I would also like to know how to use SnoopCompile better.

So, inspired by this thread I decided to ProfileView the TTFX for my package, DFTK, which currently stands at a ridiculous 90s. About 1/5 of that time is in inference, without reference to package code. Some places I can recognize are functions that have nested functions, but that is a pattern I use…

[image] Why isn't `size` always inferred to be an Integer? I don’t think the compiler reads the docs. I wander if the compiler could read assertions, though, and use that information. Question more on the subject: Can someone provide a clear step by step of what they are doing to produce thes…

[image] DNF: I don’t think the compiler reads the docs. So let it also solve this issue :smiling_imp:

You actually want to time and/or profile the first run. So start a fresh session, and: using ProfileView @profile @time using SomePackage ProfileView.view() @profview @time themainfunction(x) Although profiling slows things down a bit. I also found ProfileView struggles with really huge load times…

[image] Raf: You actually want to time and profile the first run. So start a fresh session, and: I had understood that this can profile the compilation of the profiler as well. Doesn’t it?

I assumed @profile was compiled in the base Julia image.

As a developer not very familiar with the subject “what should I write additionally to use my packages faster”, it would be nice if I have just a simple build flag that says “just precompile this package from all of its own tests, and don’t care the excessive code”.

[image] sairus7: “just precompile this package from all of its own tests, and don’t care the excessive code Don’t know how realistic is this, but definitely a good idea.

Taking TTFX seriously: Can we make common packages faster to load and use

General Usage Performance

Topic		Replies	Views
Any way to speed up loading large precompiled packages? General Usage precompilation , ttfp , ttfx	35	3578	May 15, 2023
Very slow time to first plot, 2022 General Usage ttfp	72	5090	May 8, 2023
Startup time of 1000 packages – 53% slower in Julia 1.12 vs 1.10 Internals & Design performance , ttfx , latency	81	6319	November 14, 2025
Building a PC optimized for "time to first plot" Performance	86	4790	October 23, 2022
Help reducing compilation and inference time Performance compilation , latency	71	1611	July 11, 2024

Taking TTFX seriously: Can we make common packages faster to load and use

Related topics