Performance of libasciidoc (Go) compared to asciidoctor (Ruby).

[bwklein]

I am running some side by side comparisons of the rendering time between these two products on the commandline.
Currently, it seems that the Ruby processor is ~4.7x faster than the Go implementation.

I realize that this is a project under active development and that there might not be an emphasis on performance yet in the code, but I wondered if this level of difference is expected at this time, or if the Ruby version will be faster.
When I see the rendering performance of Go based tools like Hugo, I was a bit surprised by my findings here.

Is there anything I can do differently on the commandline to improve the performance of the Go processor?

[xcoulon]

Thanks for your feedback @bwklein.
I understand your concerns and I'm currently working on some improvements at the parser level (see #820). I also made some recent changes which improved the speed, too (see #827)

May I as which version of libasciidoc you're using? 0.5 or master?
Also, could you provide me with a link to your docs, so I can run the benchmarks myself (to see how my upcoming changes would improve the overall perfs)

[xcoulon]

Also, could you provide me with a link to your docs, so I can run the benchmarks myself (to see how my upcoming changes would improve the overall perfs)

I meant: run the benchmarks and also investigate ;)

[pjanx]

The current pre-0.7.0 master is much, much faster than 0.6.0, about 6 times for me, give or take.

[bwklein]

Unfortunately I tried running the same files today as I tested back in March 2021 and it fails to parse unordered lists in my document.

I spent most of the day just trying to setup GitPod to install/run it. WAY later, I found this comment on this pull request that got things working. #847 (review)

[xcoulon]

@bwklein Argh, I still need to address this PR :/ Sorry for the time you wasted on it :(
Also, could you elaborate on how it fails to parse ordered lists in your document? Could you even open an issue for this, please?

[pjanx]

For what it's worth, I'm not seeing any regressions. What I consider a fresh annoyance is having to add:

	logrus.SetLevel(logrus.WarnLevel)

to suppress "info" messages containing the entire document.

Note that I actually use this as a module dependency. I appreciated your BREAKING CHANGES commit message markers.

[xcoulon]

For what it's worth, I'm not seeing any regressions. What I consider a fresh annoyance is having to add...

oh my bad! I will downgrade the logs with Info level to Debug. I believe it's a left-over, but wasn't intended to remain there.

Note that I actually use this as a module dependency. I appreciated your BREAKING CHANGES commit message markers.

awesome! and thanks for your feedback, I hope my changes did not cause you too much troubles, or at least that the commit messages contained all the information you needed!