La résolution de méthode, ou le coût que le cache amortit Method resolution, or the cost the cache amortizes

Résoudre un message coûte une remontée de chaîne — que le cache amortit.Resolving a message costs a chain walk — that the cache amortizes.

Le dernier volume boucle sur le premier. Si tout est un message (Vol 1), et qu'envoyer un message, c'est remonter la chaîne d'ancêtres jusqu'au premier qui répond (Vol 5), alors chaque appel a, en théorie, un coût : celui du parcours. Mais Ruby ne paie ce coût qu'une fois. Un cache mémorise, pour chaque site d'appel, la méthode trouvée ; les appels suivants la touchent directement, sans reparcourir la chaîne. C'est pourquoi des hiérarchies profondes ou des mixins multiples ne ruinent pas la performance en régime normal : la résolution est amortie. Le coût existe, mais il est presque toujours payé une seule fois — et le savoir, c'est savoir où il redevient visible.The last volume loops back to the first. If everything is a message (Vol 1), and sending a message means walking the ancestor chain to the first that answers (Vol 5), then each call has, in theory, a cost: the walk. But Ruby pays that cost only once. A cache memorizes, per call site, the method found; subsequent calls hit it directly, without re-walking the chain. That's why deep hierarchies or multiple mixins don't ruin performance in normal operation: resolution is amortized. The cost exists, but it's almost always paid once — and knowing that is knowing where it becomes visible again.

# chaque appel RÉSOUT le message en parcourant la chaîne d'ancêtres (Vol 5)
obj.value
#   → singleton class → classe → modules inclus → superclasse → … → BasicObject
#     jusqu'au premier ancêtre qui définit value

# mais Ruby n'arpente pas la chaîne à CHAQUE appel : il met en cache
obj.value   # 1er appel : résolution complète, puis mise en cache
obj.value   # appels suivants : cache touché, O(1) — la chaîne n'est pas reparcourue

String.instance_method(:upcase).owner   # => String  (résolu une fois, mémorisé)

Le cache rend les appels gratuits — method_missing en sort, et le paie.The cache makes calls free — method_missing opts out, and pays.

Deux choses contournent l'amortissement du cache. La première : method_missing (Vol 6). Par construction, il ne s'exécute qu'après l'échec du parcours complet de la chaîne — Ruby cherche partout, ne trouve rien, puis appelle ton handler. Ce double trajet se rejoue largement à chaque appel, là où une vraie méthode est résolue une fois puis touchée en O(1). La seconde : toute modification de classe à l'exécution — monkey-patch, define_method tardif, extend d'un objet — invalide des entrées du cache, forçant de nouvelles résolutions complètes. Le coût n'est donc pas « la chaîne est longue » ; c'est « je suis sur un chemin que le cache ne couvre pas ». Et la seule façon de le savoir, c'est de mesurer.Two things bypass the cache's amortization. First: method_missing (Vol 6). By construction, it runs only after the full chain walk fails — Ruby searches everywhere, finds nothing, then calls your handler. This double trip largely replays on every call, where a real method is resolved once then hit in O(1). Second: any runtime class change — monkey-patch, late define_method, extending an object — invalidates cache entries, forcing fresh full resolutions. So the cost isn't 'the chain is long'; it's 'I'm on a path the cache doesn't cover'. And the only way to know is to measure.

# method_missing : le chemin LENT, par construction
class Ghost
  def method_missing(name, *args)
    name == :value ? 42 : super
  end
  def respond_to_missing?(n, _ = false) = n == :value || super
end

Ghost.new.value
#   → parcourt TOUTE la chaîne d'ancêtres (ne trouve rien)
#   → PUIS appelle method_missing
# ce double trajet se rejoue à chaque appel : peu « cachable » comme une vraie méthode

method_missing est le chemin lent par nature : il suppose l'échec d'abord. Chaque appel paie le parcours raté plus l'indirection du handler. C'est précisément le coût que le № 1 du Vol 6 nommait « difficile à debug » — ici on ajoute « et mesurablement plus lent ». Pour un proxy appelé rarement, aucune importance ; sur un chemin chaud, ça se voit au profil.method_missing is the slow path by nature: it assumes failure first. Each call pays the failed walk plus the handler's indirection. It's exactly the cost Vol 6's № 1 called "hard to debug" — here we add "and measurably slower". For a rarely-called proxy, it doesn't matter; on a hot path, the profile shows it.

Ce qui invalide le cache — et comment mesurer au lieu de croire.What invalidates the cache — and how to measure instead of believe.

Le cache tient tant que les classes ne bougent pas. Le faire bouger à l'exécution — définir ou retirer une méthode, monkey-patcher, étendre un objet, créer une méthode singleton — invalide des entrées et force de nouvelles résolutions. En régime normal, on charge ses classes au boot puis on n'y touche plus : le cache reste chaud, tout va vite. Le coût réapparaît si on modifie des classes en boucle chaude — un define_method par requête, un patch répété. Et pour savoir si l'un de ces coûts pèse vraiment, un seul outil : la mesure. benchmark/ips compare des itérations par seconde, Benchmark.realtime chronomètre — on tranche sur des nombres, jamais sur une intuition.The cache holds as long as classes don't move. Moving them at runtime — defining or removing a method, monkey-patching, extending an object, creating a singleton method — invalidates entries and forces fresh resolutions. In normal operation, you load classes at boot then leave them alone: the cache stays warm, everything's fast. The cost reappears if you modify classes in a hot loop — a define_method per request, a repeated patch. And to know whether any of these costs truly weighs, one tool: measurement. benchmark/ips compares iterations per second, Benchmark.realtime times — you decide on numbers, never on intuition.

# ce qui INVALIDE le cache : modifier des classes À L'EXÉCUTION
class String
  def shout = upcase   # un monkey-patch tardif (Vol 6)…
end
# … invalide des caches de résolution : les sites d'appel doivent re-résoudre

# le piège n'est pas le patch lui-même, c'est de le faire EN BOUCLE :
loop do
  obj.define_singleton_method(:tick) { ... }  # redéfinit à chaque tour
  obj.tick                                      # → cache jamais stable
end

require "benchmark/ips"

Benchmark.ips do |x|
  x.report("appel direct")     { user.name }
  x.report("via send")         { user.send(:name) }
  x.compare!
end
# on COMPARE des chiffres, on ne tranche pas à l'intuition

require "benchmark"
puts Benchmark.realtime { 1_000_000.times { user.name } }
# le temps réel d'un million d'appels : un nombre, pas une impression

Le bouclage avec le Vol 1 est complet : « tout est message » a un corollaire de coût — résoudre un message demande un travail, que le cache amortit presque toujours. Comprendre ça, c'est cesser de craindre les mixins (Vol 5) et la métaprog (Vol 6) pour de mauvaises raisons, et ne s'en méfier que là où un profil le justifie. La flexibilité de Ruby n'est pas « lente » ; elle a des coûts localisés, que la mesure révèle un par un.The loop back to Vol 1 is complete: "everything is a message" has a cost corollary — resolving a message takes work, which the cache almost always amortizes. Grasping that is ceasing to fear mixins (Vol 5) and metaprogramming (Vol 6) for the wrong reasons, and distrusting them only where a profile justifies it. Ruby's flexibility isn't "slow"; it has localized costs that measurement reveals one by one.

Réécrire « pour la perf » un coût qu'aucun profil n'a montré.Rewriting "for perf" a cost no profile ever showed.

Le contre-exemple obligatoire du numéro, et la faute que le volume entier cherche à désamorcer. On a entendu que method_missing est lent (chapitre 2 : c'est vrai), alors on le remplace par deux cents méthodes générées « pour la perf ». Sauf qu'on n'a rien mesuré. Ces accesseurs sont appelés douze fois par requête, pas douze millions ; le gain par appel se compte en nanosecondes ; et il disparaît dans le bruit d'une requête HTTP qui dure des millisecondes. On a échangé un objet lisible (un method_missing avec son jumeau) contre deux cents méthodes muettes et un boot plus lourd — pour un gain qu'on n'a jamais constaté. Le coût était réel en théorie, négligeable en pratique, et seul un profil pouvait le dire.The issue's mandatory counter-example, and the fault the whole volume aims to defuse. You heard method_missing is slow (chapter 2: true), so you replace it with two hundred generated methods 'for perf'. Except you measured nothing. These accessors are called twelve times per request, not twelve million; the per-call gain is in nanoseconds; and it vanishes in the noise of an HTTP request lasting milliseconds. You traded a readable object (a method_missing with its twin) for two hundred mute methods and a heavier boot — for a gain you never observed. The cost was real in theory, negligible in practice, and only a profile could tell.

# « method_missing est lent » → on génère 200 méthodes, SANS profil
class Settings
  CONFIG.each_key do |key|
    define_method(key) { CONFIG[key] }   # 200 define_method au boot
  end
end

# ce qu'on n'a pas mesuré :
#   · ces accesseurs sont appelés ~12 fois par requête, pas 12 millions
#   · le gain par appel se compte en NANOsecondes → invisible bout à bout
#   · on a alourdi le boot et dispersé la logique en 200 méthodes muettes
# on a « optimisé » un coût qu'aucun profil n'a jamais montré

# D'abord MESURER — l'accès config est-il seulement dans le profil ?
require "benchmark/ips"
Benchmark.ips do |x|
  x.report("method_missing") { settings.timeout }
  x.report("generated")      { settings_gen.timeout }
  x.compare!
end
# si l'écart est réel ET sur un chemin chaud → générer se justifie, mesuré.
# sinon → on GARDE le method_missing lisible (avec respond_to_missing?),
# et on optimise ce que le profil a réellement pointé.