Benchmarks
Regenerated by rake bench before each release, on a quiet machine. Every chart has its table.
One page, five engines
Loading the latest numbers…
Rendering is what a production server repeats on every request. Compiling happens once per template and process: it is the first requests after a deploy, and every page in development.
Whole apps
Every .slim template compiled once, the way a fresh server process does on its first requests — only the templates both engines compile. Median of 7 runs.
Formatter and linter
Why it is faster
Compiling. Slim parses a template into an S-expression, then runs it through about twenty Temple filters, each rebuilding the tree. SlimX parses each line once with a single StringScanner into a small tree, and one compiler walks it and writes Ruby.
Rendering. The Ruby SlimX writes appends frozen strings to one buffer, escapes with ERB::Escape, the C function Rails itself uses, and inlines dynamic attributes as a case on their value, so a true, false or nil attribute costs no method call. Static attributes, classes and ids are merged at compile time.
Allocating. Each parsed node is a Struct rather than a Data (two fewer objects, 2.8 times faster to build), and the parser never slices a line it can scan in place.
Reproduce
bundle exec rake corpus:fetch # the open-source corpus, .slim files only
SLIMX_CORPUS=path/to/app/views bundle exec rake bench # adds your own appbench/compare.rb renders the same blog page from bench/compare/ in Slim, Haml and ERB, fails if any engine renders different HTML, measures with benchmark-ips under YJIT, and writes docs/benchmarks.json, which every page of this site reads.