Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: getnikola/nikola-site
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: d80d3be916c7
Choose a base ref
...
head repository: getnikola/nikola-site
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 067ca38eed5b
Choose a head ref
  • 2 commits
  • 2 files changed
  • 1 contributor

Commits on Oct 18, 2016

  1. Copy the full SHA
    57a01b6 View commit details
  2. merged

    ralsina committed Oct 18, 2016
    Copy the full SHA
    067ca38 View commit details
Showing with 58 additions and 1 deletion.
  1. +57 −0 posts/markdown-can-affect-performance.txt
  2. +1 −1 state_data.json
57 changes: 57 additions & 0 deletions posts/markdown-can-affect-performance.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
.. title: Markdown can affect performance
.. slug: markdown-can-affect-performance
.. date: 2016-10-18 12:52:55 UTC
.. tags:
.. category:
.. link:
.. description:
.. type: text
.. author: Roberto Alsina

Markdown is a very popular input format for static site generators, that's why
Nikola has supported it since very early in life, even if I prefer reSt most
of the time.

One thing that has surprised me a while ago is that, considering how minimalistic
markdown is, and how little it does, it can be pretty slow to process. But it
turns out this is not completely markdown's fault, but that the python markdown
implementation is really, *really*, **really** slow.

How slow? Let's check it out. All benchmarks in this post were done in my notebook,
a nice Asus Zenbook UX305, with a fast SSD and plenty of RAM. In all cases the builds
were done using no parallelization.

The test site is an empty site to which I added 1000 copies of a simple, not too large
markdown file (our theming guide, converted from reSt using pandoc).

As a baseline, a site with 1000 copies of the original reSt theming.txt builds in ``126`` seconds.

The markdown version of that site? It gets progressively slower as files build, so
I suspect it leaks *something* between builds, and finishes in ... ``1584```seconds. That is
over 12 times **slower** than the reSt compiler.

But you don't want to switch to reSt? No problem! We support more markdown compilers than
we probably should, so you can just choose which one you prefer.

Here is a `chart <https://getnikola.com/handbook.html#chart>`__ showing the performance of each (HTML and reSt added as reference):


.. chart:: Bar
:title: Seconds to build (bigger is worse)

'markdown', [1584]
'kramdown', [194]
'rest', [126]
'pandoc', [110]
'commonmark', [64]
'mistune', [34]
'mistune+cython', [32]
'misaka', [25]
'html', [14]

There are just a few disadvantages to using any of the alternative Markdown compilers:

* They are less tested, because fewer people use them (and if you use them, that changes!)
* They may lack a specific feature of the "standard" markdown compiler, such as extension
support (in which case, `file a bug <https://github.com/getnikola/issues>`__ with us!)
* The produced output may differ from the "standard", but that happens :-)
2 changes: 1 addition & 1 deletion state_data.json
Original file line number Diff line number Diff line change
@@ -1,3 +1,3 @@
{
"last_deploy": "2016-10-13T18:29:26.991693"
}
}