Hash-Consing

Musical scores are full of repetition. In a symphony, middle C can appear thousands of times, quarter notes dominate, and the same staccato mark is scattered across every instrument. Most notation software allocates a separate object for each of these occurrences. That means thousands of identical objects, all taking memory and I/O bandwidth for no reason.

Ooloi doesn't.

With ADR-0029, we have implemented selective hash-consing: identical immutable musical objects are represented by the same instance. The same C4, the same staccato, the same quarter note: one object, shared system-wide.

Why "Selective"?

Not everything benefits. A forte marking may appear only a handful of times; a slur always connects specific endpoints. Caching those adds overhead without real gain. So the system targets high-frequency cases (pitches, rests, chords, common articulations) and ignores the rest.

What this changes

• Memory footprint collapses: a score that would allocate hundreds of thousands of objects now reuses a fraction of them.
• File sizes shrink: less redundancy on disk and across the network.
• I/O accelerates: save/load no longer bottleneck on repeated data.
• GC pressure drops: fewer allocations, less churn.
• Scalability improves: orchestral and contemporary scores fit comfortably in memory.

All of this is transparent. Musicians won't 'use' hash-consing; they'll just notice that large works open, scroll, and save without drama.

Why it works here

In mutable architectures, shared objects are a trap: one stray modification contaminates every reference. Defensive copying and locks erase any performance benefit. In Ooloi, immutability is the rule. Sharing is safe. No copies, no locks, no bugs.

This isn't the kind of feature that makes a demo screenshot. It's one of the architectural foundations that decides whether the system will still perform when you open Mahler's 8th or La terre est une homme.

It took days to implement. That's the difference Clojure makes.