Disons que j'ai un cas en tête qui doit tomber pile poile dans le cas pathologique. Il s'agissait de parser des fichiers de petites tailles. En C, j'aurais simplement utiliser un char[] de taille "suffisante", en ocaml, buffer ne propose pas les même fonction de parse que string, la conversion est donc obligatoire.
Donc, chaque fichier utilise une string de qq ko. J'imagine que vu la taille, elle n'est pas alloué dans le tas mineur mais directement dans le tas majeur. Donc, si tu parses 10 000 fichiers, la limitation sera le GC. En jouant sur les options, j'ai gagné 15% de perf, en utilisant beaucoup plus de mémoire. J'imagine que l'idéal serait un allocateur qui recycle les vieux objets de grandes tailles, cela évite de réallouer la mémoire.
Ce cas était tellement énervant, car en C ou C++, il n'y aurait eu aucune allocation pendant la durée de la boucle. Et au final, le temps était passé dans la gestion mémoire.
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 4.
Disons que j'ai un cas en tête qui doit tomber pile poile dans le cas pathologique. Il s'agissait de parser des fichiers de petites tailles. En C, j'aurais simplement utiliser un char[] de taille "suffisante", en ocaml, buffer ne propose pas les même fonction de parse que string, la conversion est donc obligatoire.
Donc, chaque fichier utilise une string de qq ko. J'imagine que vu la taille, elle n'est pas alloué dans le tas mineur mais directement dans le tas majeur. Donc, si tu parses 10 000 fichiers, la limitation sera le GC. En jouant sur les options, j'ai gagné 15% de perf, en utilisant beaucoup plus de mémoire. J'imagine que l'idéal serait un allocateur qui recycle les vieux objets de grandes tailles, cela évite de réallouer la mémoire.
Ce cas était tellement énervant, car en C ou C++, il n'y aurait eu aucune allocation pendant la durée de la boucle. Et au final, le temps était passé dans la gestion mémoire.
"La première sécurité est la liberté"