Rationale: According to http://jsperf.com/slice-vs-loop-copy, loop-copying an array of 3 elements vs slice(0) is about 2.8 times faster on V8 and almost 2 times faster on JSC. The difference increases with the array length decrease. This is critical for event dispatching-intensive code paths (e.g. continuous DOM updates). Test: While profiling Web Inspector running against a page with lots of dynamically modified attributes, the patched version turned out to be about 30% faster than the original one (3.8 sec vs. 5.1 sec).
Created attachment 163325 [details] Patch
Comment on attachment 163325 [details] Patch This will probably regress scenarios when we have more listeners.
(In reply to comment #2) > (From update of attachment 163325 [details]) > This will probably regress scenarios when we have more listeners. We may add a check for a threshold if this optimization has a noticeable effect.
If you think performance is critical here - do copy-on-write. I.e. iterate over original and put it into the iterating-over Set. If upon addEventListener your list is in Set - clone it. Finally we put has() method into our Map and make Set implementation possible.
(In reply to comment #4) > If you think performance is critical here - do copy-on-write. I.e. iterate over original and put it into the iterating-over Set. If upon addEventListener your list is in Set - clone it. Finally we put has() method into our Map and make Set implementation possible. This was actually all about one element listeners array case. Apparently putting something into the set makes things even slower in this case. Special-casing one element case might help but I don't think that we currently have a scenario where this whole issue is a problem.
the linked jsperf shows manual copy about 75% faster than for-loop. Why can't we optimize Array.prototype.slice() instead? I'm not convinced this is a big perf issue right now, since jsperf is probably not representative of how WI code will be optimized.
<rdar://problem/19281542>
We replaced this code recently.