bminer / node-blade

Blade - HTML Template Compiler, inspired by Jade & Haml
Other
320 stars 28 forks source link

Benchmark #180

Closed daslicht closed 11 years ago

daslicht commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

I was also curious. :)

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

daslicht commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 11 years ago

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 11 years ago

something else ? You are a musician either?

bminer commented 11 years ago

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 11 years ago

Thank you very much for this extensive explanation !