Allocations cachées & le GC, ou compter plutôt que craindre Hidden allocations & the GC, or counting rather than fearing

Chaque "…", [], {} alloue — et le GC paie pour libérer.Every "…", [], {} allocates — and the GC pays to free.

Après la résolution, l'autre coût du dynamisme : la mémoire. En Ruby, presque tout est un objet (Vol 1), et créer un objet l'alloue sur le tas. Chaque littéral de chaîne, de tableau, de hash que tu écris fabrique un nouvel objet — y compris les identiques, réalloués à chaque passage. Plus tard, le ramasse-miettes (GC) parcourt le tas pour libérer ce qui n'est plus référencé : c'est un travail, proportionnel au nombre d'objets créés. Une seule allocation ne coûte rien ; un million dans une boucle chaude déclenche des cycles de GC qui, eux, se voient. La règle reste celle du volume : on ne devine pas une allocation, on la compte.After resolution, the other cost of dynamism: memory. In Ruby, almost everything is an object (Vol 1), and creating an object allocates it on the heap. Every string, array, hash literal you write makes a new object — including identical ones, reallocated on each pass. Later, the garbage collector (GC) scans the heap to free what's no longer referenced: that's work, proportional to the number of objects created. A single allocation costs nothing; a million in a hot loop triggers GC cycles that do show. The rule stays the volume's: you don't guess an allocation, you count it.

# chaque LITTÉRAL crée un objet — invisible, mais réel
"abc".object_id == "abc".object_id   # => false  deux String distincts
[].object_id == [].object_id         # => false  deux Array
{}.object_id == {}.object_id         # => false  deux Hash

# … sauf ceux qui sont uniques par nature (Vol 1) :
:abc.object_id == :abc.object_id     # => true   un seul Symbol
1.object_id   == 1.object_id         # => true   un seul Integer

# compter, plutôt que deviner :
before = GC.stat(:total_allocated_objects)
1_000.times { "ligne".dup }
GC.stat(:total_allocated_objects) - before   # => ~2000 objets : le littéral ET sa copie, à chaque tour

Deux codes identiques à l'œil allouent très différemment.Two codes identical to the eye allocate wildly differently.

La surprise du numéro : l'allocation est invisible dans le texte. Un littéral écrit à l'intérieur d'une boucle — un séparateur ", ", un hash de défaut, un tableau temporaire — est recréé à chaque itération, alors qu'à la lecture rien ne distingue ce cas d'un littéral hissé, alloué une seule fois. Sur cent mille lignes, c'est cent mille objets de différence, donc autant de pression sur le GC. On ne le voit pas en relisant ; on le voit en comptant. GC.stat(:total_allocated_objects) avant et après donne le nombre exact d'objets créés — et transforme une intuition (« ça doit allouer ») en fait (« ça alloue tant »).The issue's surprise: allocation is invisible in the text. A literal written inside a loop — a separator ", ", a default hash, a temporary array — is recreated on each iteration, while at a glance nothing distinguishes it from a hoisted literal, allocated once. On a hundred thousand lines, that's a hundred thousand objects of difference, hence that much GC pressure. You don't see it on rereading; you see it by counting. GC.stat(:total_allocated_objects) before and after gives the exact number of objects created — turning an intuition ("that must allocate") into a fact ("that allocates this much").

# le SÉPARATEUR est recréé à chaque ligne — invisible à l'œil
def to_csv(rows)
  rows.map do |row|
    row.join(", ")          # ", " : un littéral réalloué à CHAQUE tour
  end
end

before = GC.stat(:total_allocated_objects)
to_csv(rows_100k)
GC.stat(:total_allocated_objects) - before
# => bien plus que 100_000 : chaque ", " compte, + les chaînes jointes

Rien ne signale le problème : row.join(", ") se lit comme du Ruby propre. Mais ", " est un littéral, donc un objet neuf à chaque ligne. Sur 100 000 lignes, c'est 100 000 chaînes de séparateur jetées aussitôt — invisibles, jusqu'à ce que GC.stat les compte ou qu'un cycle de GC se montre dans le profil.Nothing flags the problem: row.join(", ") reads as clean Ruby. But ", " is a literal, hence a fresh object per line. On 100,000 lines, that's 100,000 separator strings discarded at once — invisible, until GC.stat counts them or a GC cycle shows in the profile.

Trois instruments : GC.stat, ObjectSpace, memory_profiler.Three instruments: GC.stat, ObjectSpace, memory_profiler.

On ne raisonne sur les allocations qu'avec des chiffres, et Ruby en fournit trois sources. GC.stat ouvre le tableau de bord du ramasse-miettes : total_allocated_objects (le cumul depuis le démarrage, idéal en delta avant/après), les objets vivants, le nombre de cycles déjà déclenchés. ObjectSpace.count_objects donne une photo par type — combien de String, d'Array, de Hash existent à l'instant T. Et memory_profiler, le plus directement utile, enveloppe un bloc et te dit où la mémoire est partie : par gem, par fichier, par ligne. C'est lui qui transforme « ça alloue trop quelque part » en « ligne 14, un Hash par row, deux mégaoctets ».You reason about allocations only with numbers, and Ruby provides three sources. GC.stat opens the garbage collector's dashboard: total_allocated_objects (the cumulative since startup, ideal as a before/after delta), live objects, the number of cycles already triggered. ObjectSpace.count_objects gives a snapshot by type — how many String, Array, Hash exist right now. And memory_profiler, the most directly useful, wraps a block and tells you where the memory went: by gem, by file, by line. It's the one that turns 'it allocates too much somewhere' into 'line 14, a Hash per row, two megabytes'.

# GC.stat : l'état global du tas et le total alloué depuis le départ
GC.stat(:total_allocated_objects)   # compteur cumulatif d'objets créés
GC.stat(:heap_live_slots)           # objets vivants actuellement
GC.stat(:minor_gc_count)            # combien de cycles de GC déjà passés

# ObjectSpace : combien d'objets, par type, à l'instant T
ObjectSpace.count_objects
# => { T_STRING: 48210, T_ARRAY: 9123, T_HASH: 1840, ... }

require "memory_profiler"

report = MemoryProfiler.report do
  import(rows)                # le bloc qu'on suspecte
end
report.pretty_print          # alloué par GEM, par FICHIER, par LIGNE, par CLASSE

# le rapport NOMME le coupable :
#   allocated memory by location
#     2.10 MB  app/import.rb:14   ← le Hash + 5 String par ligne, ×100_000
# on ne cherche plus à l'aveugle : on lit où la mémoire part vraiment

La méthode tient en trois temps : profile (memory_profiler autour du bloc suspect), lis où part la mémoire (la ligne, la classe), corrige ce point précis (hisser un constant, geler une chaîne, éviter un intermédiaire) — puis re-mesure pour confirmer le gain. Jamais l'ordre inverse : optimiser d'abord, espérer ensuite.The method is three beats: profile (memory_profiler around the suspect block), read where the memory goes (the line, the class), fix that precise spot (hoist a constant, freeze a string, avoid an intermediate) — then re-measure to confirm the gain. Never the reverse: optimize first, hope after.

Geler et « pooler » partout — en optimisant les allocations qui ne pèsent pas.Freezing and "pooling" everywhere — optimizing the allocations that don't weigh.

Le contre-exemple obligatoire du numéro. Convaincu que « le GC est lent », on éparpille des .freeze, on pré-alloue des buffers, on évite les littéraux partout — guidé par l'intuition, pas par un profil. Résultat : on durcit du code froid (un en-tête rendu une fois par heure, des constantes de boot) pour des gains nuls, et on alourdit la lisibilité au passage. Pendant ce temps, le vrai point chaud — une boucle d'import qui alloue un hash et cinq chaînes par ligne, cent mille fois — n'a jamais été ouvert, parce qu'on ne l'a pas mesuré. On a optimisé les allocations qu'on imaginait, pas celles que memory_profiler aurait comptées. Le réflexe du volume vaut aussi pour la mémoire : profile, corrige le point chaud que le rapport nomme, laisse le reste lisible.The issue's mandatory counter-example. Convinced that 'the GC is slow', you scatter .freeze, pre-allocate buffers, avoid literals everywhere — guided by intuition, not a profile. Result: you harden cold code (a header rendered once an hour, boot constants) for zero gain, and hurt readability along the way. Meanwhile, the real hot spot — an import loop allocating a hash and five strings per line, a hundred thousand times — was never opened, because you didn't measure it. You optimized the allocations you imagined, not the ones memory_profiler would have counted. The volume's reflex holds for memory too: profile, fix the hot spot the report names, leave the rest readable.

# « le GC est lent, je gèle et je pool PARTOUT » — sans memory_profiler
KEYS = %w[host port user].map(&:freeze).freeze   # micro-gain… au boot (froid)

def render_header
  buf = String.new                # « éviter une allocation »
  buf << "X-App: ".freeze          # .freeze éparpillés par superstition
  buf                              # ← cette méthode tourne 1×/heure
end

# pendant ce temps, le VRAI point chaud n'a jamais été regardé :
def import(rows)
  rows.map { |r| { id: r[0], name: r[1], tags: r[2].split("|") } }
end                                # un Hash + des String + un Array par ligne,
                                   # × 100_000 lignes — invisible, jamais profilé

# D'abord profiler, ensuite corriger LE point chaud
require "memory_profiler"
MemoryProfiler.report { import(rows) }.pretty_print
#   2.4 MB  import.rb:2   ← le rapport pointe la boucle d'import, pas le header

# on corrige CE que le profil montre, et on re-mesure le gain :
TAG_SEP = "|"
def import(rows)
  rows.map { |r| { id: r[0], name: r[1], tags: r[2].split(TAG_SEP) } }
end
# le header à 1×/heure ? on le laisse lisible : son allocation ne compte pas