Not 100% sure what you mean but if you measure the time to render a HTML fragment 100 times the total time is 1 x pre-compilation + 100 x rendering. The pre-compilation has virtually no effect on the total time.
I mean that if you do the HTML parsing to JavaScript portion as part of your deploy, instead of in the browser at render time, then all you're measuring is string concatenation and HTML render times, which should always be the same. Template rendering speeds in that case mean nothing.
Exactly - with the proliferation of Grunt in most modern webapp builds, it is incredibly simple to pre-compile your templates in your production builds. In fact, it's so fast (and I get useful stacktraces when my tpls have errors) that I started precompiling templates in development, too.
I find the bottleneck is 99% the browser's HTML parser and 1% the actual templating library.
If somebody had any tips on how to bring down the "Parse HTML" time spent in the Chrome inspector (see Timeline), I would be interested to know. Tips other than, of course, "parse less HTML".
What a weird factor to use for choosing a template engine. Also there already is a popular unit test framework called riot.js