Improve HelperMap.has performance

[jlukic]

The in keyword in javascript is notoriously slow in javascript.

In FF in performs approximately ~300x slower, chrome ~0.3x slower depending on test.

I originally noticed this method popping up a bunch in CPU profiles for a meteor app.

This PR replaces HelperMap.has with what should be a faster method of accessing existence.

Some perfs
https://jsperf.com/hasownproperty-vs-in-vs-undefined/12
https://jsperf.com/checking-if-a-property-exists/10

As an aside, typecasting with '' + value (the existing setup) is the most performant way
https://jsperf.com/convert-to-string-bj/3

[apollo-cla]

@jlukic: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[mitar]

Hm, interesting. But how often is this called? Only when one defined helpers on a template? This is not often, no?

[jlukic]

My understanding is that lookup checks for template helpers 2nd in lookup list - Line 162

if (template && ((helper = Blaze._getTemplateHelper(template, name, boundTmplInstance)) != null)) {

getTemplateHelper immediately checks if this is a helper - Line 40

if (template.__helpers.has(name)) {

So anything that hits 2+ in lookup: i.e lexical scope, data context has to hit this function, which is why it gets called a lot.

[mitar]

Ooo, good good. :-)

One more thing. Should we just replace that map with ES6 Map? And use ecmascript package to polyfill it? I am not sure about performance in this case, but probably it should be cleaner?

[arggh]

Is this PR missing something? Any performance improvements would be most welcome.

[mitar]

Yes. We can merge this.

[mitar]

Thanks!