As noted by Ryosuke in bug 77906, our code review pages are putting quite some strain on WebKit. For the specific example <https://bugs.webkit.org/attachment.cgi?id=125284&action=review> we are allocating ~40MB below EventTarget::addEventListener(). We should experiment with making EventListenerMap use a Vector rather than a HashMap to store the listener vectors. The hash map solution may very well be overkill, it's quite unusual to have listeners for more than 1 or 2 event types on a given Node. A quick hack-up yields a ~26MB reduction in memory usage without making EventListenerMap show up in profiles on our PerformanceTests/. I'll sleep on it, but I have a good feeling about this.
Maybe we can use Vector and do the binary search for lookups?
Created attachment 162792 [details] 30-day trial version for EWS
Comment on attachment 162792 [details] 30-day trial version for EWS Attachment 162792 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13793242 New failing tests: inspector/console/command-line-api-getEventListeners.html
Created attachment 162996 [details] Proposed patch
The memory savings here is awesome, so I'm going to say r+. But are we missing the larger lesson here? Why are sparse hash tables so huge? Could we save even more memory by fixing that as well?
Comment on attachment 162996 [details] Proposed patch r=me
Committed r128002: <http://trac.webkit.org/changeset/128002>