Reuse Compiled Code Between REPLs?

Hi all,

A newbie question: Can the first-time compilation time be avoided when running the same function in different REPL sessions? Specifically, if I execute a function in the terminal REPL and then want to run the same function in the VSCode REPL, can I somehow reuse the compiled code from the terminal REPL to avoid recompilation in the VSCode REPL?

Thanks!

Well not easily. The only option to reuse compiled code is to create a sysimg e.g. with PackageCompiler.jl.

Note that precompiled code is shared automatically between julia sessions (as long as you don’t mess with JULIA_DEPOT).

1 Like

Some nuance here. First we have to clarify what “running the same function” means. Let’s say you ran foo(1, "bar"), so you expect to run foo(1, "bar") again in another REPL session and do the exact same thing. Thing is, foo(1, "bar") isn’t even guaranteed to do the same thing within the same session. The symbol foo’s behavior, even existence, depends on its parent module/namespace and the (package) environment. If either are different, then the answer is reasonably no. For a simple example, MyModule.foo can behave differently from YourModule.foo, even if the method’s expression is identical because of something as small as a global constant variable like pi having a different value.

For that reason, almost every way of caching compiled code for the runtime involves a package, which has a module and an environment. If an importable unit in an active Julia process isn’t exactly what you’re going for, PackageCompiler.jl and JuliaScript.jl repurpose the package system. As an exception, StaticCompiler.jl can compile an executable from Julia (subset) function that doesn’t rely on the runtime; it’s not explicitly tied to a module or environment but the code behavior still implicitly does.

2 Likes

Maybe what you are after is RemoteREPL.jl ? This way you can access the full julia kernel of a different process.

2 Likes

Relevant discussion on Github from a few hours ago:

There’s also DaemonMode.jl (no idea if it’s still functional, no updates for a few years).

2 Likes

Thanks! It sounds like what I had in mind; from the docs of PackageCompiler.jl:

You can save loaded packages and compiled functions into a file (called a sysimage) that you pass to julia upon startup. Typically the goal is to reduce latency on your machine

I will give it a try and come back. By the way, why did you mention that my original question was not easily achievable? Have you already tried the package?

Thanks, but I think I am not getting completely your point; I might need extra knowledge on this.

Thing is, foo(1, "bar") isn’t even guaranteed to do the same thing within the same session.

With the above, do you mean different behavior and outcome after applying the same foo(1, "bar") function in different REPL sessions? Or just different behavior? I guess if the function behaves differently but achieves the same, does not matter that much for my purposes.

I guess by “not easily” I mean “not out of the box”. Using PackageCompiler.jl requires some amount of effort.
Tbh I never used it myself but I think it shouldn’t be too hard to create a custom sysimg - though the compilation takes a bit of time I’ve heard. And you’ll need to recreate the sysimg everytime you want to have different functions.

If the same things are needed repeatedly, you can create custom Startup packages.

1 Like

I meant either, but in this case you should care about different behavior alone because that rules out reusing compiled code.

1 Like

Thanks, I will try this! I didn’t know I could create custom Startup packages with PrecompileTools.jl.