Benchmark #180

Closed
daslicht opened this Issue Jul 3, 2013 · 9 comments

Projects

None yet

2 participants

daslicht commented Jul 3, 2013

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

Owner
bminer commented Jul 3, 2013

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.

Owner
bminer commented Jul 24, 2013

I was also curious. :)

paularmstrong/node-templates#13

@bminer bminer closed this Jul 24, 2013
daslicht commented Aug 6, 2013

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

Will this get be better in production ?

Owner
bminer commented Aug 6, 2013

@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.

Owner
bminer commented Aug 6, 2013

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 commented Aug 6, 2013

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 commented Aug 6, 2013

something else ? You are a musician either?

Owner
bminer commented Aug 7, 2013

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 commented Aug 7, 2013

Thank you very much for this extensive explanation !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment