EDIT po Markdown Test Suite zmarła, gdy Commonmark wyszedł trybie stealth (w ten sposób marnowania dużej ilości czasu pracy open source ...), I rozwidlone część porównywania wielu realizacji (w większości napisane przez Ciebie naprawdę) w https://github.com/cirosantilli/commonmark-implementation-compare
testy prędkości jest naiwne, ale daje wyobrażenie:
blackfriday 2.1222s 235 46%
cmark 1.9516s 1 0%
commonmarkjs 37.4651s 2 0%
hoedown 1.8875s 221 43%
kramdown 94.6460s 247 48%
markdown2 28.9707s 278 54%
markdown_pl 14.6919s 287 56%
markdownjs 40.3337s 302 59%
marked 35.3758s 258 50%
maruku 87.1664s 316 61%
multimarkdown 2.0579s 239 46%
pandoc 6.3442s 268 52%
peg_markdown 2.6402s 211 41%
rdiscount 42.0547s 200 39%
redcarpet 43.6608s 229 44%
showdown 45.0655s 285 55%
prawdopodobnie największą wadą jest to, że każdy badany wejście jest zasilane ze standardowego wejścia, tak tłumaczy nazywane są za każdym razem, i cierpią dużą głową.
Możliwość używa Suite Markdown test: https://github.com/karlcow/markdown-testsuite
Czy ./cat-all.py a następnie uruchomić swoje testy na all.tmp.md
Obecnie zawiera 103 testów, a już obsługuje wiele silników przecenowych.
Proste testy porównawcze zostały już wykonane dla całkowitego czasu poszczególnych testów (także znaczącego parametru), a wdrożenie go na wyjściu z cat-all.py byłoby naprawdę łatwe.
Dzięki, dobrze wiedzieć. Czy formaty zagnieżdżania (np. Pogrubienie wewnątrz kursywy wewnątrz tekstu linku) wpływają na wydajność? –
Zadaj to jako kolejne pytanie, nie pytaj mnie. Nie jestem ekspertem od skoków cenowych - właśnie to wczoraj zdarzyło mi się ustawić na moim blogu! – Skilldrick
Co więcej, prawdopodobnie zależy to od implementacji (wracając do dyskusji Joela i Jeffa na temat stanu maszyn w porównaniu do stanu maszyn). Spójrz na swoje źródło implementacji i zobacz, jak radzi sobie z zagnieżdżaniem. – Skilldrick