Stream: helpdesk (published)

Topic: `@time_imports` and precompilation

Alec (Oct 28 2023 at 04:48):

If something takes a long time with @time_imports, does it likely mean that (more) precompile statements would help or are the causes separate? I'm trying to diagnose and speed up my package's load time.

Jakob Nybo Nissen (Oct 28 2023 at 15:55):

Precompile statements wouldln't help much with that. The good news is that it's absolutely possible to make your package load faster! You should

• Use Julia 1.10 if possible. Loading packages has been optimised for Julia 1.10 relative to Julia 1.9
• Cut down on dependencies, if possible

• Gate optional features of packages behind pkg extensions - this can reduce the total number of dependencies by quite a lot
  ... and now for the actual optimisation of loading time:

• Use Aqua.jl to make sure that your package doesn't commit type piracy.

• Make sure your package is type stable - or more precisely, that every variable's type is known at compile time when running your package
• A few packages use metaprogramming to programmatically define gigantic methods, or define tens of thousands of methods. Avoid these packages and don't do it yourself
• Make sure your dependencies don't commit type piracy, and that they are type stable, too

Jakob Nybo Nissen (Oct 28 2023 at 15:57):

There is a sense in which the above is pretty easy: Don't commit type piracy, write inferrible code, and don't use metaprogramming to generate massive packages.
The hard part is - if you have an existing stack with your package and a lot of dependencies, how can you tell exactly which type instability in your dependencies cause issues such that you can surgically fix these issues instead of rewriting 20 different packages? For this, use SnoopCompile. But I'm afraid it'll be a bit of "invalidation whack-a-mole". The real solution is to use type-stable packages.

jar (Oct 28 2023 at 17:37):

Make sure your package is type stable - or more precisely, that every variable's type is known at compile time when running your package

What distinction are you making here?

Alec (Oct 29 2023 at 04:26):

I'm afraid it'll be a bit of "invalidation whack-a-mole". The real solution is to use type-stable packages.

That's what I'm running into with JET and SnoopCompile - seems like both are highlighting pretty deep sources for possible call errors and invalidations respectively. :(

Jakob Nybo Nissen (Oct 29 2023 at 08:31):

jar said:

What distinction are you making here?

Type stability is (was?) normally considered to only apply to whether the return type could be inferred from the input types. Whereas I'm talking about all variables. Someone called this "type groundedness" but the term hasn't caught on. Maybe "inferrible" is more common

Jakob Nybo Nissen (Oct 29 2023 at 08:33):

Alec: Is this in Base or stdlib packages, or third-party packages? You can try to add issues upstream and maybe a few PRs. I think it would be good to begin pushing people to release inferrible code into the ecosystem. Still today I hear from people who think inferribility is only something you care about in hot loops and due to performance.

Alec (Oct 29 2023 at 22:11):

Third party packages. I’m going to rewatch some of the 2021 JuliaCon presentations on latency and try to grok that stuff better so when I open issues I can be more constructive (and maybe even submit PRs)

Alec (Oct 30 2023 at 01:53):

First upstream improvement in process of being registered :) https://gitlab.com/aplavin/AccessorsExtra.jl/-/issues/2

Last updated: Nov 06 2024 at 04:40 UTC