Performance
You are reading the documentation of an outdated version, whose text may no longer be accurate. Go to the latest version.
These figures are for v0.3.0, which renders slides
concurrently and parses its fonts once
(go-slides/slides#11).
go-slides and marp-cli 4.5.1 were run as subprocesses on the same decks, on an Apple M4 Max (16 CPUs) with a 1-minute load average under 8, five interleaved rounds after a warm-up. Time is the median wall time; memory is the peak of the whole process tree (marp-cli drives a Chrome, whose processes count).
| Deck | Output | go-slides | marp-cli | go-slides memory | marp-cli memory |
|---|---|---|---|---|---|
| 100 slides | HTML | 36 ms | 315 ms | 47 MiB | 140 MiB |
| 100 slides | 1.14 s | 1.88 s | 242 MiB | 1,509 MiB | |
| 100 slides | PNG, every slide | 0.97 s | 5.44 s | 225 MiB | 1,354 MiB |
| 100 slides | PPTX | 3.39 s | 8.03 s | 530 MiB | 1,373 MiB |
| gaia, 20 slides | 283 ms | 1.57 s | 154 MiB | 1,315 MiB | |
| math and code, 20 slides | PNG, every slide | 250 ms | 2.32 s | 168 MiB | 1,286 MiB |
Why it is fast
- No browser to start. marp-cli launches Chrome for every PDF, image and PPTX export; go-slides renders with go-webengine inside its own process.
- Slides render in parallel, four at a time by default, and each image is written as soon as it is its turn: a long deck is never held in memory as images.
- Fonts are parsed once per process, not once per slide.
What it does not win
- PDF size. Each slide is an image in the PDF, where Chrome prints text and vectors: 10 MiB against 837 KiB for the 100-slide deck.
- CPU time on big decks. Four workers spend more CPU than the wall time shows: 3.2 s against marp-cli’s 2.7 s for the 100-slide PDF.
- Memory is an upper bound for marp-cli: Chrome’s processes share pages that the sum counts in each. Its largest single process is 220–320 MiB.
The method, every deck and mode, and the commands to reproduce the figures are in BENCHMARKS.md.
Created on by tannevaled
Modified on by tannevaled