--- title: "impl Fn() vs. Box: Le Duel du Dispatch des Closures en Rust" description: "Comparaison du static et dynamic dispatch pour les closures en Rust, focus sur performance et cas d'usage" url: "https://mayorana.ch/fr/blog/closure-dispatch-rust-fr" language: "fr" date: "2025-11-05" author: "Mohamed Bennekrouf" tags: - "rust" - "closures" - "dispatch" - "performance" - "traits" en_version: "https://mayorana.ch/en/blog/closure-dispatch-rust.md" --- # impl Fn() vs. Box: Le Duel du Dispatch des Closures en Rust Le système de closures de Rust offre deux façons de gérer un comportement function-like : `impl Fn()` pour le static dispatch et `Box` pour le dynamic dispatch. Chacune a des caractéristiques distinctes de performance et flexibilité, guidées par l'ownership, les traits, et les lifetimes de Rust. Je vais les comparer et expliquer quand choisir l'une plutôt que l'autre.

## `impl Fn()` face à `Box` | **Aspect** | **impl Fn() (Static Dispatch)** | **Box<dyn Fn()> (Dynamic Dispatch)** | |------------|--------------------------------|--------------------------------------| | **Mécanisme de Dispatch** | Monomorphized au moment de la compilation (zero-cost) | Utilise des vtables (runtime lookup) | | **Performance** | Plus rapide (~1–2 ns, appel direct) | Plus lent (~5–10 ns, vtable lookup) | | **Flexibilité** | Type concret unique par instance | Peut stocker des closures hétérogènes | | **Mémoire** | Stack-allocated (sauf si moved) | Heap-allocated (fat pointer + heap data) | | **Cas d'Usage** | Type de closure fixe, critique en performance | Comportement dynamique, types de closures multiples | ## Décider en pratique ### 1. impl Fn() (Static Dispatch) - **Utilise Quand** : - Le type de closure est fixe et connu au moment de la compilation. - La performance est critique (ex : hot loops, systèmes embarqués). - Les [zero-cost abstractions](https://mayorana.ch/fr/blog/zero-cost-abstractions-rust) sont désirées. - **Pourquoi** : Le compilateur génère une fonction unique pour chaque type de closure via monomorphization, permettant l'inlining et aucun overhead runtime. **Exemple** : ```rust fn make_adder(x: i32) -> impl Fn(i32) -> i32 { move |y| x + y } fn main() { let add_five = make_adder(5); // Type: closure(5) println!("{}", add_five(3)); // 8 } ``` Pas d'allocation heap, appels de fonction directs, et performance optimale. ### 2. Box<dyn Fn()> (Dynamic Dispatch) - **Utilise Quand** : - Tu dois stocker différentes closures dans la même collection (ex : callbacks). - Les types de closures varient au runtime (ex : systèmes de plugins). - La flexibilité l'emporte sur les coûts de performance. - **Pourquoi** : `dyn Fn()` utilise une vtable pour la résolution de méthode au runtime, permettant des closures hétérogènes au coût d'allocation heap et d'overhead de lookup. **Exemple** : ```rust fn create_op(is_add: bool) -> Box i32> { if is_add { Box::new(|x, y| x + y) } else { Box::new(|x, y| x * y) } } fn main() { let add = create_op(true); let mul = create_op(false); println!("{} {}", add(2, 3), mul(2, 3)); // 5 6 } ``` Supporte le comportement dynamique, idéal pour les event handlers ou plugins. Remarque que `create_op` n'est pas seulement *plus lent* avec `impl Fn` — c'est impossible. Chaque littéral de closure reçoit son propre type anonyme : les deux branches renvoient donc deux types sans rapport, alors qu'`impl Trait` promet exactement un seul :

## Considérations de Lifetime - **Box<dyn Fn()>** : Nécessite des lifetimes explicites si la closure capture des références : ```rust struct Handler<'a> { callback: Box &'a str + 'a>, } ``` - **impl Fn()** : Les lifetimes sont typiquement inférées sauf si des références sont capturées, simplifiant l'usage. ## Trade-offs de performance | **Scénario** | **impl Fn()** | **Box<dyn Fn()>** | |--------------|---------------|-------------------| | **Vitesse d'Appel** | ~1–2 ns (appel direct) | ~5–10 ns (vtable lookup) | | **Overhead Mémoire** | Aucun (stack-allocated) | 16–24 bytes (fat pointer + heap data) | | **Code Bloat** | Possible (monomorphization) | Minimal (vtable unique) | ## Plus loin ### Collection de Closures Hétérogènes ```rust // ✅ Dynamic dispatch permet ceci fn create_handlers() -> Vec String>> { vec![ Box::new(|x| format!("Double: {}", x * 2)), Box::new(|x| format!("Square: {}", x * x)), Box::new(|x| format!("Cube: {}", x * x * x)), ] } fn main() { let handlers = create_handlers(); for (i, handler) in handlers.iter().enumerate() { println!("Handler {}: {}", i, handler(5)); } } ``` ### Static dispatch avec génériques ```rust // ✅ Static dispatch avec type parameter fn process_data(data: &[i32], processor: F) -> Vec where F: Fn(i32) -> i32, { data.iter().map(|&x| processor(x)).collect() } fn main() { let numbers = vec![1, 2, 3, 4, 5]; // Chaque appel est monomorphized let doubled = process_data(&numbers, |x| x * 2); let squared = process_data(&numbers, |x| x * x); println!("Doubled: {:?}", doubled); println!("Squared: {:?}", squared); } ``` ### Event System avec Dynamic Dispatch ```rust use std::collections::HashMap; type EventHandler = Box; struct EventSystem { handlers: HashMap>, } impl EventSystem { fn new() -> Self { Self { handlers: HashMap::new(), } } fn subscribe(&mut self, event: &str, handler: F) where F: Fn(&str) + Send + Sync + 'static, { self.handlers .entry(event.to_string()) .or_insert_with(Vec::new) .push(Box::new(handler)); } fn emit(&self, event: &str, data: &str) { if let Some(handlers) = self.handlers.get(event) { for handler in handlers { handler(data); } } } } fn main() { let mut system = EventSystem::new(); // Différents handlers pour le même event system.subscribe("user_login", |data| { println!("Logging: User {} logged in", data); }); system.subscribe("user_login", |data| { println!("Analytics: Track login for {}", data); }); system.emit("user_login", "alice"); } ``` ## Patterns d'Optimisation ### Éviter Dynamic Dispatch dans les Hot Paths ```rust // ❌ Mauvais - dynamic dispatch dans une boucle critique fn bad_hot_loop(data: &[i32], op: &dyn Fn(i32) -> i32) -> Vec { let mut result = Vec::new(); for &x in data { result.push(op(x)); // Vtable lookup à chaque itération } result } // ✅ Bon - static dispatch fn good_hot_loop(data: &[i32], op: F) -> Vec where F: Fn(i32) -> i32, { let mut result = Vec::new(); for &x in data { result.push(op(x)); // Inlined } result } ``` ### Hybrid Approach ```rust // Combiner les deux approches selon le contexte enum Operation { Static(fn(i32) -> i32), // Function pointer (fast) Dynamic(Box i32>), // Closure (flexible) } impl Operation { fn call(&self, x: i32) -> i32 { match self { Operation::Static(f) => f(x), Operation::Dynamic(f) => f(x), } } } fn main() { let ops = vec![ Operation::Static(|x| x * 2), // Compile-time connu Operation::Dynamic(Box::new(|x| x + 10)), // Runtime flexible ]; for op in &ops { println!("{}", op.call(5)); } } ``` ## Benchmarking ### Setup de Benchmark avec Criterion ```rust use criterion::{black_box, criterion_group, criterion_main, Criterion}; fn bench_dispatch(c: &mut Criterion) { let static_fn = |x: i32| x * 2 + 1; let dynamic_fn: Box i32> = Box::new(|x| x * 2 + 1); c.bench_function("static_dispatch", |b| { b.iter(|| static_fn(black_box(42))) }); c.bench_function("dynamic_dispatch", |b| { b.iter(|| dynamic_fn(black_box(42))) }); } criterion_group!(benches, bench_dispatch); criterion_main!(benches); ``` ### Résultats typiques ``` static_dispatch time: [1.2345 ns 1.2456 ns 1.2567 ns] dynamic_dispatch time: [8.7654 ns 8.8765 ns 8.9876 ns] ``` **Observation** : `impl Fn()` est ~7x plus rapide que `Box`. ## Memory Layout et Overhead ### Static Dispatch Memory Layout ```rust use std::mem; fn analyze_static() { let x = 42; let closure = |y| x + y; println!("Static closure size: {} bytes", mem::size_of_val(&closure)); // Typiquement 4 bytes (taille de x capturé) } ``` ### Dynamic Dispatch Memory Layout ```rust fn analyze_dynamic() { let x = 42; let closure: Box i32> = Box::new(move |y| x + y); println!("Dynamic closure size: {} bytes", mem::size_of_val(&closure)); // Typiquement 16 bytes (fat pointer: 8 bytes data + 8 bytes vtable) // Plus l'allocation heap pour les données capturées } ``` ## Quel dispatch choisir **Choisis `impl Fn()` pour** : - Code sensible aux performances (ex : chaînes d'iterators). - Type de closure unique (ex : factory functions). - Zero-cost abstractions. **Choisis `Box` pour** : - Comportement dynamique (ex : event handlers, plugins). - Stockage de types de closures mixtes (ex : `Vec>`). - Flexibilité runtime. **Exemples Réels** : - `impl Fn()` : Utilisé dans les adaptateurs d'iterators comme `map` et `filter` pour une performance zero-cost. - `Box` : Commun dans les frameworks GUI pour les callbacks d'événements où la flexibilité est clé. ## Verification de performance Pour quantifier la différence de performance, benchmark avec `criterion` : ```rust use criterion::{black_box, Criterion}; fn bench(c: &mut Criterion) { let impl_fn = |x: i32| x + 5; let dyn_fn: Box i32> = Box::new(|x| x + 5); c.bench_function("impl_fn", |b| b.iter(|| impl_fn(black_box(3)))); c.bench_function("dyn_fn", |b| b.iter(|| dyn_fn(black_box(3)))); } ``` `impl Fn()` est plus rapide et utilise moins de mémoire. ## Conclusion Utilise `impl Fn()` pour un dispatch static zero-cost dans les scénarios critiques en performance avec des types de closures connus. Opte pour `Box` quand la flexibilité est nécessaire, comme dans les systèmes de plugins ou applications event-driven nécessitant du polymorphisme runtime. Le système d'ownership et de traits de Rust assure que les deux approches sont sûres, le choix dépendant de l'équilibre entre performance et exigences dynamiques.