Dans la pratique, on se retrouve rarement à traiter des énormes fichiers markdown.
Cependant je me suis amusé à faire un petit benchmark sur une liste (* foo -> <li>foo</li>)
lines
pandoc RAM
pandoc time
awk RAM
awk time
5k
109.7
1.13
2.7
0.02
10k
119.8
2.19
2.7
0.02
50k
172.2
10.65
2.7
0.14
100k
261.0
21.5
2.7
0.27
1M
crash
2.7
2.83
Très gratifiant de vois l'occupation RAM constante (en MB) et l'exécution environ 100x plus rapide.
Mais au delà de la sobriété en ressource, je pense aussi que ce n'est souvent pas plus compliqué en terme d'effort intellectuel, voire plus simple, de penser son algo en ligne à ligne plutôt qu'en globale.
Ce cas md2html est peut être débattable, chacun jugera de la simplicité du script. J'ai vu des implémentations de ce cas d'usage avec des tonnes d'expression régulière qui ne me donnerai pas envie d'y mettre le nez.
Pour des cas plus simples, ce sera encore plus flagrant j'imagine.
[^] # Re: Moi aussi j'aime bien lire les histoires de développeurs
Posté par steph1978 . En réponse au journal écriture d'un script AWK de transformation de Markdown en HTML. Évalué à 8. Dernière modification le 22 octobre 2025 à 12:18.
Dans la pratique, on se retrouve rarement à traiter des énormes fichiers markdown.
Cependant je me suis amusé à faire un petit benchmark sur une liste (
* foo-><li>foo</li>)Très gratifiant de vois l'occupation RAM constante (en MB) et l'exécution environ 100x plus rapide.
Mais au delà de la sobriété en ressource, je pense aussi que ce n'est souvent pas plus compliqué en terme d'effort intellectuel, voire plus simple, de penser son algo en ligne à ligne plutôt qu'en globale.
Ce cas md2html est peut être débattable, chacun jugera de la simplicité du script. J'ai vu des implémentations de ce cas d'usage avec des tonnes d'expression régulière qui ne me donnerai pas envie d'y mettre le nez.
Pour des cas plus simples, ce sera encore plus flagrant j'imagine.