handlebars performance in release 1.0.0

[iamolivinius]

Today, I did this comparison of handlebars.1.0.0:
http://jsperf.com/mustache-against-handlebars

Because of the unexpected performance of handlebars I also did another one with handlebars1.0.rc.1:
http://jsperf.com/mustache-against-handlebars/2

I'm not absolutely positive if I set up the benchmark properly. Someone should verify the benchmark code first.

[kpdecker]

:/

I don't see anything obviously wrong with those test cases. This is something that we will need to look into.

[kpdecker]

http://static.incaseofstairs.com/handlebars-perf/ has some performance numbers, run on my local machine.

http://cl.ly/image/320k03123F1m
In particular there were a few changes relating to @data that hit the case that you have above. I've made a few changes on master that improve the performance hit there.

The performance tests exposed a number of other performance hits so I'm going to leave this bug open to

1. Investigate what the other performance hits are
2. Get the performance tracking implementation up and running on CI and the graph integrated into the site.

[kpdecker]

There are two things that impacted our performance here

1. @data being enabled for all cases.

   For this one I've added a note in the optimizations section stating that this should be disabled if someone is experiencing performance issues here.

2. Helpers and partials were being merged for every execution of a partial which could have been quite a few. I was able to update this to avoid that case, greatly improving the performance.

Closing this out as I think the primary cases are handled and while we are not quite at the performance numbers of the rc1 release we are still generally as fast or faster than all of the other engines that we have in our benchmark suite.

I'll continue to see what sort of optimizations can be done independent of this bug as I find that fun :)