Pimp My IDE / Garage Dispatch
← Back to the garage
September 13, 2026 · Julia / REPL craft / performance

Latency is interface.

Julia 1.13 tunes the distance between intent and feedback: faster startup and precompile work, cheaper full collections, a real fuzzy history lane, syntax color, paste that behaves on Windows, and better tools for finding where the waiting lives.

The take: “faster” is not one number. A developer feels startup, package load, first useful work, repeat work, interruption, and search as separate control surfaces. Tune and report them separately or your benchmark is just chrome polish.
Strap into the Latency Dyno ↓

The first result is part of the language.

Julia 1.13’s release post says package precompilation is roughly 30% faster than 1.12 and startup is about 20% faster in the project’s reported tests. It also says the team now tracks time-to-first-X against 39 community-submitted workflows, separating precompile, load, and execution costs.[1] That decomposition matters more than the victory lap.

A language can have glorious steady-state throughput and still feel like a sticky throttle if the edit-run-observe loop makes you wait. The user does not experience “runtime performance” as an abstract aggregate. They experience the pause after Enter.

A fast engine with a sleepy ignition is still a sleepy car at every red light.

Julia tuned the cockpit, not only the motor.

The new REPL adds syntax highlighting, automatic closing delimiters, and an fzf-style history search. Windows gets bracketed paste, so the terminal can distinguish a pasted block from keystrokes and process it correctly. The official release notes also add --trace-eval for locating top-level evaluation progress and hangs.[2]

Those are not decorative conveniences. Search, paste, interruption, and visible parse state shorten the loop between “I know what I want” and “the machine understood me.” They are latency work wearing interaction-design coveralls.

Measure the road you actually drive.

The community TTFX collection asks contributors for tiny representative workloads that avoid network access and system mutation beyond temporary and cache directories. Each task reports package load time, script run time, and total time; the repository explicitly warns that community snippets still deserve precautions such as containers.[3]

That is the right shape for an IDE bench: pin the toolchain, define one useful action, split cold load from work, repeat warm runs, and print the environment. Do not transplant a geometric mean from somebody else’s machine into your team’s workflow and call the ergonomics solved.

The quieter GC change may own the long session.

Julia’s release article explains that full GC no longer walks immutable objects loaded from system and package images as if they were ordinary heap objects. The project reports large reductions in full-collection time in its examples, while noting that young-generation collections are not affected.[1] Translation: the benefit depends on the shape and age of your heap, not a universal magic multiplier.

That distinction is exactly why long-lived editor kernels need session-shaped tests. Benchmark the first plot, the fiftieth edit-run cycle, the interrupt after a bad call, and the memory profile after the packages you actually keep loaded.

A five-pass garage test.

  1. Pin the chassis: Julia version, project and manifest revisions, CPU, OS, thread settings, depot state.
  2. Name the first useful X: first plot, first query, first model fit, first language-server answer—not “hello world” unless that is the job.
  3. Split the timer: process startup, package load, first work, warm repeat, and full session.
  4. Exercise recovery: history search, large paste, Ctrl-C, rerun, and a deliberately slow or broken path.
  5. Publish the receipt: exact command, sample count, cache state, summary statistic, spread, failures, and raw output.
Interactive makeover / benchmark discipline

Latency Dyno.

Traditional purpose replaced: paste one benchmark screenshot and declare the IDE fast. Better version: four keyboard-native dyno clamps combine experiment design, a physical load cell, live readiness language, and a copyable receipt without pretending the checklist measured performance.

Clamp the experiment

Close a clamp only when the benchmark definition contains that evidence. The rollers show setup completeness, not speed.

Latency benchmark evidence clamps

Load-cell readout

DYNO OPEN: the benchmark claim has no attached experiment shape.

0/4clamps defined
Open the four-source service manual
[1] Julia 1.13 Highlights, September 10, 2026 — project-reported TTFX, startup, GC, scheduler, REPL, Pkg, and compression changes, with methods and machine caveats. [2] Julia v1.13 release notes — canonical feature and compatibility inventory, including REPL behavior, trace-eval, hashing changes, tests, and introspection. [3] Julia TTFX Snippets — community workload format, load/run/total output contract, contribution constraints, and execution caution. [4] Hacker News item 49642645 — Julia 1.13 community discussion; discovery and practitioner context, not authority for release behavior or benchmark results.

Source boundary: the four-position gauge counts selected experiment-design clamps. It is a checklist state—not milliseconds, speedup, trust, production telemetry, or proof that a benchmark ran. Fill the blank host fields and attach raw output before making a performance claim.