Benchmark

[daslicht]

Hi, do you already benchmarked Blade?

It would be interesting to see how it compares to swig:

http://paularmstrong.github.io/node-templates/benchmarks.html

[bminer]

Indeed. I'd love to see how Blade holds up against some of the other template engines. Compiling will be relatively slow, but I'd expect rendering performance to be very similar to Jade templates.

[bminer]

I was also curious. :)

https://github.com/paularmstrong/node-templates/pull/13

[daslicht]

I recently used dynamic imports and noticed a kind of less good performance : GET / 200 410ms - 768b

Will this get be better in production ?

[bminer]

@daslicht - Yes and no. Blade can cache views automatically for you by passing in {"cache": true} to Blade's compile functions. See https://github.com/bminer/node-blade#bladecompilestring-options-cb

However, you may note that caching is turned off by default. Don't worry; this is okay. Express.js has built-in view caching that is enabled when process.env.NODE_ENV=="production" This means that the first time a user hits your website, the view rendering will be quite slow... say 410ms in your case. But after that initial compilation, future renderings of the same view should be MUCH MUCH faster.

So, I'd try running your Node server with NODE_ENV=production set in the environment and see what kind of stats you get. Hope that helps! Let me know what you think.

[bminer]

Also, you can manually turn on view caching in Express with something like: app.enable("view cache")

See http://expressjs.com/api.html#app-settings

[daslicht]

Thank you very much for you extensive reply, I really appreciate that. So when I set the app to production I should not encounter those high latencies anymore?

The caching topic is quite interesting, how does a view decided if the cache needs to be updated?

[daslicht]

something else ? You are a musician either?

[bminer]

Sure, no problem. Yes, when you set the app to production, you will experience high latency the first time that the view is compiled and rendered. After that, view renderings occur very quickly.

Express stores compiled views into a cache (in RAM). So, if you change the view (i.e. you modify the *.blade file), then the changes will not take effect until you restart your server. Express won't bother reading your changes from the hard disk. This is usually okay since you are in a production environment anyway, and it wouldn't make sense to start making view changes without a server restart. Blade's built-in cache using the {cache: true} compiler option basically works in the same way.

To be clear, only the compiled view is cached, not specific renderings of that view. Essentially, a compiled view is nothing more than a JavaScript function that returns some HTML or XML. That function is still executed each time you render the view with different view locals, but these functions are often very fast. Typically, there is not much going on except a lot of string concatenations.

And, yes, I used to study piano. Unfortunately, I'm taking a bit of a break from it to focus on work on other things. Next year will be the time to start back up again.

[daslicht]

Thank you very much for this extensive explanation !