# Why does everything keep precompiling?

**URL:** <https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109>\
**Category:** General Usage\
**Tags:** precompilation\
**Created:** [August 31, 2026, 12:37am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109 "2026-08-31T00:37:48Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![BananaMaster3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bananamaster3/32/218457_2.png) [@BananaMaster3](https://discourse.julialang.org/u/BananaMaster3)\
**Post date:** [August 31, 2026, 12:37am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/1 "2026-08-31T00:37:48Z")

</div>

Hey everybody!

I’ve been using julia more and more recently, and it’s been great. The one thing that I’m finding difficult is the thing stopping me from using the language itself – that being precompilation.

Whenever I import my package in the REPL to develop, many of it’s dependencies must precompile (the most common being Makie). I don’t understand why: Makie hasn’t changed, can’t it just use the previous compilation?

Is there any reason why Makie needs to precompile every day?  
I’m using Revise.jl.

---

<div class="post-metadata">

**Author:** ![Ronis\_BR](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ronis_br/32/50999_2.png) [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)\
**Post date:** [August 31, 2026, 1:00am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/2 "2026-08-31T01:00:30Z")

</div>

I cannot affirm categorically, but for some reasons I am also seeing much more recompilations than normal.

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [August 31, 2026, 3:26am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/3 "2026-08-31T03:26:16Z")

</div>

Hi, I use Julia by long time and I never completely understood it 🙂🙂

The general issue is named _invalidation_: adding some stuff makes assumptions the compiler relied to no longer valid and it needs to recompile. There are tools to investigate what this “stuff” actually is, what keep invalidating your compiled code, but someone else will be able to be more precise than me…

---

<div class="post-metadata">

**Author:** ![Salmon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/salmon/32/22968_2.png) [@Salmon](https://discourse.julialang.org/u/Salmon)\
**Post date:** [August 31, 2026, 7:53am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/4 "2026-08-31T07:53:03Z")

</div>

> [@sylvaticus](#):
>
> adding some stuff makes assumptions the compiler relied to no longer valid and it needs to recompile.

Since ive also had some issues recently: do you mean adding packages?  
For me it sometimes precompiles even though no packages are being added.

For what its worth, here are some cases that I have seen to cause precompilation even if no packages are being added (though I still see this issue sometimes so there may be other reasons as well):

1. Working on different machines that are sharing the same .julia folder. This one is pretty logical. Julia compiles with CPU architecture in mind so if you switch the machine it needs to precompile again.
2. Unfortunately configured AI agents: if they use the same julia depot as you they may start julia with a different optimization level cause the precompile cache to be invalidated. One can configure them to use a different path to store the precompile cache and many of the issues go away.

I guess overall I would check it there are any processes/workflows you use that require the compiler to generate new binaries. He solution is to use a separe path to store the precompile cache for each of these.  
Hope it helps - im curious if theres more coming out I am also becoming a bit frustrated waiting for Makie to precompile over and over 😃

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [August 31, 2026, 8:51am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/5 "2026-08-31T08:51:26Z")

</div>

One annoying reason you may see many packages precompile twice, is when running `] test`. This has something to do with `--check-bounds=yes` being forced in test I believe, which should hopefully finally be fixed in 1.13 [Pkg.jl/CHANGELOG.md at master · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/blob/master/CHANGELOG.md#pkg-v113-release-notes)

---

<div class="post-metadata">

**Author:** ![heliosdrm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/heliosdrm/32/3851_2.png) [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)\
**Post date:** [August 31, 2026, 9:27am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/6 "2026-08-31T09:27:04Z")

</div>

I experience unexpected precompilation when I switch from project A to B (each one with its particular `Project.toml`+`Manifest.toml`), and then back to A, even if nothing in A had changed. It happens more frequently (or more heavily) if the Manifests of A and B have different versions of the same packages. Does it make sense?

(Note: I usually work with the VS Code extension, so there might be also an interaction with this, I don’t know.)

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 31, 2026, 11:40am UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/7 "2026-08-31T11:40:52Z")

</div>

I don’t know all the causes, but there are a few broad categories. First, it’s worth reviewing what precompilation is caching, given your observation that `Makie` hasn’t changed. Despite the phrase “package precompilation”, the module is not actually instantiated once per package or version. For a minimal example, a package `A@1.0.0` depends on packages `B@1.x.x` and `C@1.0.0`. If I add `A@1.0.0` to a fresh environment and load it, I instantiate `A@1.0.0`, the latest `B@1.2.3`, and `C@1.0.0`. If I add `B@1.0.0` and `A@1.0.0` to another fresh environment and load `A`, I instantiate `A@1.0.0`, `B@1.0.0`, and `C@1.0.0`. Obviously, both environments can use the same `C@1.0.0` instance, and the different `B` versions need different ones. Less obviously, there are 2 `A@1.0.0` instances because of the dependency on different `B` versions; something as simple as a `B` function being automatically inlined into an `A` function requires this. The number of environments to which you have ever added a package is a more reasonable estimate than the number of versions, but precompilation _also_ depends on the Julia process’ compiler settings.

With that in mind, we can recognize some potential problems:

1. It’s not great to accumulate hundreds of caches over time or even in one sitting of reproducing many old projects. The Julia installation thus has a [cutoff](https://docs.julialang.org/en/v1/manual/environment-variables/#JULIA_MAX_NUM_PRECOMPILE_FILES) for the number of instances to cache at once per package. If you cycle through enough environments across different sessions, then you’d discard a cached instance before you could reuse it. The cutoff is documented to default to 10, but I don’t know how to verify it at runtime, and as others have pointed out, it appears to be a lot less.
2. Activating multiple environments within a single session can cause version conflicts with loaded package instances. Usually, we’d get a warning in the REPL to restart the session if we don’t want to re-precompile packages for a mixed and possibly broken state of environments.
3. A mixed state also occurs when stacking environments. There are not many ways to stumble into that and the Pkg API isn’t designed to encourage it, but it does show up often because all of our custom environments are stacked on the Julia version’s default environment.

For a minimal example of a mixed state from the packages you mentioned, let’s say I have `Revise@3.14` in the default environment and switch to another environment with only the latest `GLMakie` installed (both environments previously precompiled their lone packages in separate sessions):

```julia-auto
(@v1.12) pkg> st
Status `C:\Users\Benny\.julia\environments\v1.12\Project.toml`
⌃ [295af30f] Revise v3.14.5
Info Packages marked with ⌃ have new versions available and may be upgradable.

(@v1.12) pkg> activate onlymakie\\
  Activating project at `C:\Users\Benny\onlymakie`

(onlymakie) pkg> st
Status `C:\Users\Benny\onlymakie\Project.toml`
  [e9467ef8] GLMakie v0.13.13

julia> using GLMakie

julia> LOAD_PATH
3-element Vector{String}:
 "@"
 "@v#.#"
 "@stdlib"

```

Cool, I reached the precompile cache just fine. But `GLMakie` wasn’t the only package I could load. `LOAD_PATH` shows the stacked environments in order of where packages are searched: `@` means the currently active one, `@v#.#` refers to the default versioned environment, and `@stdlib` refers to the standard library. So what happens if I load `Revise` from the default environment?

```julia-auto
julia> using Revise
[Info: Precompiling Revise [295af30f-e4ad-537b-8983-00126c2a3abe](cache misses: wrong dep version loaded (1))
Precompiling Revise finished.
  1 dependency successfully precompiled in 14 seconds

```

Earlier I said I had already precompiled `Revise` for the default environment. However, `GLMakie` had already loaded `OrderedCollections@2.0.1` here, which is not the same version (`⌅ 1.8.2`) in the pre-existing `Revise` instance. That triggers a precompile, and with `JULIA_DEBUG=loading`, we’d see a few relevant “Rejecting cache file” lines repeated somewhere in the wave of “Loading object cache file” lines. That wasn’t a long wait though, the other way around is much worse. In a fresh session:

```julia-auto
julia> using Revise # we load the default instance, maybe in startup.jl

(@v1.12) pkg> activate onlymakie\\
  Activating project at `C:\Users\Benny\onlymakie`

julia> using GLMakie # the wrong OrderedCollections is loaded, so...
[Info: Precompiling GLMakie [e9467ef8-e4e7-5192-8a1a-b1aee30e663a](cache misses: wrong dep version loaded (1))
Precompiling GLMakie finished.
  20 dependencies successfully precompiled in 401 seconds. 280 already precompiled.
  2 dependencies precompiled but different versions are currently loaded (OrderedCollections and Preferences). Restart julia to access the new versions. Otherwise, 153 dependents of these packages may trigger further precompilation to work with the unexpected versions.

```

I didn’t have to precompile everything from scratch, but the \<10% of dependencies took \>50% the time of a full precompile. We also get the warning to restart Julia to use this precompile, though I can’t verify whether the precompile is for the mixed state or repeated for the proper state. Even if I avoid loading `Revise` in a new session, I have to precompile this bit for the proper `GLMakie` again:

```julia-auto
(@v1.12) pkg> activate onlymakie\\
  Activating project at `C:\Users\Benny\onlymakie`

julia> using GLMakie
[Info: Precompiling GLMakie [e9467ef8-e4e7-5192-8a1a-b1aee30e663a]
Precompiling GLMakie finished.
  20 dependencies successfully precompiled in 603 seconds. 280 already precompiled.

```

As you might have inferred from my deliberate use of an older `Revise` version, this wouldn’t be a problem if I used the latest `Revise`:

```julia-auto
(@v1.12) pkg> st
Status `C:\Users\Benny\.julia\environments\v1.12\Project.toml`
  [295af30f] Revise v3.17.0

julia> using Revise

(@v1.12) pkg> activate onlymakie\\
  Activating project at `C:\Users\Benny\onlymakie`

julia> using GLMakie

```

This latest-update convenience is a consequence of package developers keeping up with the popular parts of the ecosystem. `GLMakie` also has a relatively large number of dependencies to run into loaded version conflicts, and we can often get away with smaller environments that don’t overlap in one session. In the general case, we do have to be careful about keeping incompatible environments away from each other and resyncing environments (`resolve`) after changes to the `dev`-ed packages’ project files, even as Julia improves how we can handle conflicts.

---

<div class="post-metadata">

**Author:** ![Wen-Wei\_Tseng](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wen-wei_tseng/32/28839_2.png) [@Wen-Wei\_Tseng](https://discourse.julialang.org/u/Wen-Wei_Tseng)\
**Post date:** [August 31, 2026, 12:28pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/8 "2026-08-31T12:28:09Z")

</div>

Increasing `JULIA_MAX_NUM_PRECOMPILE_FILES` ([Environment Variables · The Julia Language](https://docs.julialang.org/en/v1/manual/environment-variables/#JULIA_MAX_NUM_PRECOMPILE_FILES)) might help.

---

<div class="post-metadata">

**Author:** ![ianshmean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ianshmean/32/216042_2.png) [@ianshmean](https://discourse.julialang.org/u/ianshmean)\
**Post date:** [August 31, 2026, 12:30pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/9 "2026-08-31T12:30:48Z")

</div>

Avoiding `pkg> activate ...` and just using `--project` directly helps, especially if you load packages in your startup.jl.

Also, behavior and messaging around this has improved in 1.13. I’m keen to see what people make of 1.13

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [August 31, 2026, 1:17pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/10 "2026-08-31T13:17:26Z")

</div>

I do think this is very frequently related to things in `startup.jl`.

You can also ask Julia itself to give you more debug information about why it’s re-precomiling. Set `JULIA_DEBUG=loading` to get this extra output:

> **[Environment variables - Logging · The Julia Language](https://docs.julialang.org/en/v1/stdlib/Logging/#Environment-variables)**
>
> The Logging module provides a way to record the history and progress of a computation as a log of events. Events are created by inserting a logging statement into the source code, for example: | Documentation for The Julia Language.

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [August 31, 2026, 7:12pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/11 "2026-08-31T19:12:32Z")

</div>

It would be nice to have a resolver mode that minimizes the number of distinct package versions. Maybe an idea for a package…

---

<div class="post-metadata">

**Author:** ![JonasWickman](https://avatars.discourse-cdn.com/v4/letter/j/9de0a6/32.png) [@JonasWickman](https://discourse.julialang.org/u/JonasWickman)\
**Post date:** [August 31, 2026, 8:36pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/12 "2026-08-31T20:36:06Z")

</div>

I think it’s in the works: [GitHub - StefanKarpinski/Resolver.jl · GitHub](https://github.com/StefanKarpinski/Resolver.jl)

I could have sworn I saw `@StefanKarpinski` giving a talk about it a Juliacon, but I cannot find it now.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [August 31, 2026, 8:40pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/13 "2026-08-31T20:40:20Z")

</div>

> [@JonasWickman](#):
>
> I think it’s in the works: [GitHub - StefanKarpinski/Resolver.jl · GitHub](https://github.com/StefanKarpinski/Resolver.jl)

I don’t think that does anything w.r.t that.

However, from [Pkg.jl/CHANGELOG.md at master · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/blob/master/CHANGELOG.md#pkg-v19-release-notes:)

> - To reduce the amount of time spent downloading and precompiling new package versions when working with multiple environments, a new preserve strategy `PRESERVE_ALL_INSTALLED` has been added which will preserve all existing dependencies and only add versions of the new packages that are already installed. i.e. `pkg> add --preserve=installed Foo`. Also a new tiered resolve strategy `PRESERVE_TIERED_INSTALLED` that tries this first, which can be set to the default strategy by setting the env var `JULIA_PKG_PRESERVE_TIERED_INSTALLED` to `true` ([#3378]).

---

<div class="post-metadata">

**Author:** ![sob](https://avatars.discourse-cdn.com/v4/letter/s/65b543/32.png) [@sob](https://discourse.julialang.org/u/sob)\
**Post date:** [August 31, 2026, 9:02pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/14 "2026-08-31T21:02:46Z")

</div>

I switched to a 64 cores machine just for Julia. It helps… marginally.

---

<div class="post-metadata">

**Author:** ![ianshmean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ianshmean/32/216042_2.png) [@ianshmean](https://discourse.julialang.org/u/ianshmean)\
**Post date:** [August 31, 2026, 9:09pm UTC](https://discourse.julialang.org/t/why-does-everything-keep-precompiling/139109/15 "2026-08-31T21:09:13Z")

</div>

In 1.13:

> - The Pkg REPL `add` command now prefers versions of packages that are already loaded in the current Julia session when resolving dependencies. This helps maintain compatibility with code already running in your session; run `pkg> up` afterwards to update to the latest compatible versions. The functional `Pkg.add` API keeps the previous (loading-independent) behavior by default for reproducibility; pass `Pkg.add(pkg; prefer_loaded_versions=true)` to opt in. ([#4507])

In 1.14:

> - `Pkg.activate` now warns when packages already loaded into the session differ from what the newly activated environment specifies (different version or source path). This makes accidental reproducibility issues and unnecessary recompilation easier to spot. ([#4679](https://github.com/JuliaLang/Pkg.jl/pull/4679))

See this tracking issue for related issues/PRs [Improve the messaging around re-precompilation · Issue #4680 · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/issues/4680)

The above is from [Pkg.jl/CHANGELOG.md at master · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/blob/master/CHANGELOG.md)