improve performance of Ember.guidFor and Ember.generateGuide on

[stefanpenner]

Ember.Objects

Ember's guidKey uses defineProperty so that it is not enumerable,
this is a great idea, but can cost be a hard hit. Luckily though,
we pre-shape all ember objects to have a GUID_KEY slot. Unfortunately,
in guidFor and generateGuid we redefine the property. Not only is this
wasteful, but Object.defineProperty is incredibly costly.

Some micro-benchmarks:

• http://jsperf.com/generate-guid-key
• http://jsperf.com/faster-guid-for-test

more to come.

The cost of guidFor is about 5 - 10 times faster on Ember.Objects, and can still be improved.

// super scientific quick test.
var pool = []; for(var i =0; i < 10000; i++) { pool.push(Ember.Object.create()); }

console.time('guid');

for (var p = 0; p < pool.length; p++) {
  Ember.guidFor(pool[p]);
}

console.timeEnd('guid');

and the cost to Object.create seems essentially 0. Their is a slight memory usage increase for never guid'd Ember.Object's as they store their guid Number.

If we continue to need guid's I wonder if we should always store them merely as the integer value.

related, @ebryn is working on some directions which mitigate the need for defineProperty on some objects (like views). If we can drop these safely across the board it would be a large win.

[stefanpenner]

@ebryn pointed out this has some safety issues with pojos.

[stefanpenner]

this test is the POJO safety issue @ebryn pointed out, we may want to ensure this makes it back into master, even if this experiment does not.

[EDIT] as it turns out this thing we thought was a break, is actually how it always was..

[stefanpenner]

this only improves first-guid of an object, we can still improve more.

[lukemelia]

Nice!