This is definitely the case. Recent performance guidance from V8 developers strongly discouraged the use of 'delete' so I've gone to some lengths to avoid using it in my own code, mostly through design (trying to avoid scenarios that require the deletion of attributes). If this guidance isn't accurate anymore, I certainly never heard about it. Then again engine developers have said that they intentionally avoid publishing performance guidance since people continue to follow it after it becomes outdated - so I guess this is just support for that policy. :/
Anyway! I spent an hour or so building a simplified real-world benchmark for Object.freeze, by modifying a HTML5 game port to use Object.freeze at construction time for its immutable structured objects. These objects are basically simple tuples of integers/floats that are frequently constructed and passed around - think a Vector2 or Point data structure, etc. This file has detailed timings from the latest versions of Chrome Canary and Firefox Nightly with the Object.freeze call disabled and enabled, respectively, along with a URL you can hit to run it yourself: https://dl.dropbox.com/u/1643240/freeze%20timings.txt I'm pleased to report that Object.freeze does not seem to cause an enormous performance hit in v8 anymore. Hooray! Unfortunately, the call to Object.freeze itself shows up as a bottleneck in V8 profiles, and the 'freeze enabled' version is slower in both versions (though at least only slightly slower). So, I guess you could start using freeze in applications now if your users are all on latest FF/Chrome, and hope that in the future it will actually make you faster. Feel free to let me know if you have any questions (though if they're questions about the benchmark, maybe don't spam es-discuss with them :) ) -kg On Thu, Feb 14, 2013 at 11:56 AM, Herby Vojčík <he...@mailbox.sk> wrote: > > > Andreas Rossberg wrote: >> >> On 14 February 2013 19:26, Herby Vojčík<he...@mailbox.sk> wrote: >>> >>> I meant "de facto". People wanting to remove property bar from foo do not >>> write `delete foo.bar` anymore; they (at least some significant subset) >>> have >>> learned to write `foo.bar = null;` or `foo.bar = undefined;`. The reason >>> is >>> perf - `delete` deoptimized hidden classes. >> >> >> And with ES6, those people will hopefully realise that for those >> cases, using a Map is a cleaner alternative anyway. > > > No, it is another scenario. If an object is used as a Map, it should degrade > to HashMap, it's ok. > > The problem is proliferation of `foo.bar = null` in "normal" code, where > sometimes you want to remove some property (maybe it was an expando, or it > is realy not needed any more in the actual phases of the lifecycle). In such > cases, doing `delete` would degrade your optimized instance into a Hash. > Thus, people do `foo.bar = null` even if what they want to do is `delete > foo.bar`. > >> /Andreas > > > Herby > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
