Julia App Deployment: Reducing Startup Time with Trimming

The Hook: The "Just-in-Time" Trap

You have built a high-performance Julia application. It processes data 10x faster than the Python equivalent once it's running. But when you deploy it as a CLI tool or a serverless function (e.g., AWS Lambda), you hit a wall: Startup Latency.

A simple Hello World in Julia can take 200-500ms. Add a heavy dependency like DataFrames or Flux, and your "Time to First Plot" (TTFP) balloons to 10+ seconds. In a containerized microservice environment where pods autoscale, or in CLI tools where user experience depends on responsiveness, a 10-second cold start is a non-starter.

The community promises that "Trimming" (stripping away unused code) is the future of Julia deployment. While fully automated, granular tree-shaking is slating for stabilization in late 2025/2026, you cannot wait that long. You need to deploy today.

Here is how to achieve near-instant startup times and reduced memory footprints right now using PackageCompiler.jl with aggressive stdlib filtering—the manual precursor to automatic trimming.

The Why: Anatomy of the Lag

To fix the problem, we must understand the execution pipeline. When you run julia script.jl, the runtime performs these steps:

Bootstrapping: Loads libjulia and the default system image (sys.so). This default image is bloated; it contains the compiler, the package manager (Pkg), distinct testing frameworks, and linear algebra libraries, regardless of whether you use them.
Parsing & Lowering: Reads your code and converts it to Julia IR.
Type Inference: The heavy lifter. Julia analyzes types to generate specialized code.
Codegen (LLVM): Converts Julia IR to LLVM IR, then compiles it to native machine code.
Invalidation: If your packages extend Base methods, pre-compiled cache files from the standard library might be invalidated, forcing a re-compile.

In a standard run, steps 3 and 4 happen Just-In-Time (JIT). This is great for exploration but terrible for deployment.

We solve this by moving the JIT work to build time and "trimming" the bootstrap phase by removing unused standard libraries from the system image.

The Fix: Custom Sysimages with Stdlib Filtering

We will build a custom system image that:

Precompiles your specific method calls (eliminating JIT).
Trims unused standard libraries (reducing RAM usage and load time).

Prerequisites

Assume a standard project structure:

/MyService
  ├── Project.toml
  ├── Manifest.toml
  ├── src
  │   └── MyService.jl
  └── scripts
      └── build.jl

1. The Application Code (`src/MyService.jl`)

We will create a service that uses JSON3 (a common source of compilation latency due to heavy type inference).

module MyService

using JSON3
using Dates

# A struct representative of a data payload
struct LogEntry
    timestamp::DateTime
    level::String
    message::String
    tags::Vector{String}
end

# The function we want to be instant
function process_log(json_input::String)
    try
        data = JSON3.read(json_input, LogEntry)
        # Simulate processing logic
        return JSON3.write(Dict(
            "status" => "processed",
            "latency_check" => "passed",
            "received_at" => string(data.timestamp)
        ))
    catch e
        return JSON3.write(Dict("error" => "Invalid format"))
    end
end

# Entry point for CLI/Service
function main()
    # In a real app, this reads from stdin or HTTP
    input = """{"timestamp": "2023-10-27T10:00:00", "level": "INFO", "message": "System boot", "tags": ["sys", "boot"]}"""
    println(process_log(input))
end

end # module

2. The Build Script (`scripts/build.jl`)

This is where the magic happens. We use PackageCompiler.jl to create a shared object (.so, .dll, or .dylib) that replaces the default Julia sysimage.

We use two critical arguments:

precompile_execution_file: Runs the code during the build to capture the compiled machine code.
filter_stdlibs=true: The "Trimming" mechanism. It analyzes your dependency tree and excludes standard libraries (like Pkg, Test, SparseArrays) that you aren't using.

using PackageCompiler
using Pkg

# Ensure we are using the project environment
Pkg.activate(joinpath(@__DIR__, ".."))
Pkg.instantiate()

println("🚀 Starting Build Process...")

# Define the path for the precompile script (see step 3)
precompile_script = joinpath(@__DIR__, "precompile.jl")

# Define output name
lib_name = Sys.islinux() ? "sys_trimmed.so" : 
           Sys.isapple() ? "sys_trimmed.dylib" : "sys_trimmed.dll"
output_path = joinpath(@__DIR__, "..", lib_name)

create_sysimage(
    [:MyService, :JSON3]; # Packages to bake in
    sysimage_path = output_path,
    project = joinpath(@__DIR__, ".."),
    
    # CRITICAL: This executes your code to record compiled methods
    precompile_execution_file = precompile_script,
    
    # THE TRIMMING: Remove unused stdlibs from the image
    # This significantly reduces memory footprint and load time
    filter_stdlibs = true,
    
    # Replace default entry point (optional, good for CLIs)
    script = joinpath(@__DIR__, "entrypoint.jl") 
)

println("✅ Build Complete: $output_path")

3. The Precompile Script (`scripts/precompile.jl`)

This script must exercise every code path you expect to be fast. If you miss a branch here, it will JIT-compile at runtime (causing lag).

using MyService
using JSON3
using Dates

# 1. Exercise the happy path
json_success = """{
    "timestamp": "2023-10-27T10:00:00", 
    "level": "INFO", 
    "message": "Warmup", 
    "tags": ["test"]
}"""
MyService.process_log(json_success)

# 2. Exercise the error path (exceptions generate significant code)
json_fail = """{"bad": "json"}"""
MyService.process_log(json_fail)

# 3. Exercise the main entry point
MyService.main()

4. The Entrypoint (`scripts/entrypoint.jl`)

A small wrapper to execute main when the binary starts.

using MyService
MyService.main()

The Explanation: Why This Works

Breaking the Dependency Chain

By setting filter_stdlibs=true, PackageCompiler inspects the Project.toml of the packages you listed ([:MyService, :JSON3]). It realizes that your application does not need SuiteSparse, OpenBLAS, or the Pkg manager itself to run production logic.

In a standard Julia boot, these libraries are initialized, allocating memory and registering methods. Removing them reduces the "Resident Set Size" (RSS) of the process. For a microservice, this can mean the difference between consuming 600MB and 150MB of RAM.

Ahead-of-Time (AOT) Compilation via Snapshotting

When create_sysimage runs the precompile_execution_file:

It starts a Julia process.
It runs your functions.
The JIT compiler emits native machine code into memory.
PackageCompiler dumps the state of the heap and the executable code segment into the new .so file.

When you run with this new image, Julia doesn't need to infer types or generate code for JSON3.read or your LogEntry struct. The machine instructions are already there, effectively behaving like a C++ binary for those specific paths.

Running the Deployment

To run your application with the trimmed image:

# Generate the image
julia scripts/build.jl

# Run application with the custom image
# -J points to the image
# --q suppresses the banner
# --project points to environments (needed unless standalone app built)
julia -J sys_trimmed.so --project=. -e 'using MyService; MyService.main()'

The Results

On a typical machine, comparing the standard runtime vs. the trimmed sysimage:

Metric	Standard Julia	Trimmed Sysimage	Improvement
Startup to Output	~1.8s	~0.08s	22x Faster
Memory (RSS)	~350MB	~120MB	65% Reduction

Conclusion

While the Julia roadmap promises "static compilation" and automatic tree-shaking in upcoming versions, you do not need to wait for 1.12 or 1.13 to put Julia in production.

By leveraging PackageCompiler.jl to explicitly bake compilation traces and aggressively filter standard libraries, you effectively "trim" the runtime today. This transforms Julia from a high-latency research tool into a viable, snappy runtime for CLIs and microservices.

Programming Tutorials

Search This Blog