52695 - Coalesce XBL handlers of the same type

Status: RESOLVED FIXED

(Core :: XBL, defect, P3)

Description

[David Hyatt]

Event handlers of the same type on a given XBL binding should be coalesced, 
e.g., we have 31 event handlers on <input type="text"> and <textarea> elements.  
Since all of these handlers are of type "keypress", they could be coalesced into 
a very intelligent uber-handler that looked at hashed masks to figure out which 
XBL <handler> elements are matched. :)

Comment 1

[David Hyatt]

Shown to be a performance problem.  Nominating for nsbeta3.

Comment 2

[Peter Trudelle]

need info: do we have metrics on any user-visible performance degradation caused
by this?

Comment 3

[David Hyatt]

Ok, I did some profiling and the results I get indicate that this is not a big 
performance problem.  It used to be a problem in older profile runs because the 
XBL handlers had not been optimized.  Now that they have, things are much 
better.

I can break this down into three areas.

(1) Bloat caused by having 31 handlers per textfield.
  I did notice that I'm using non-atomized raw strings as member variables in 
the event handlers.  Fixing that will make the bloat from the 31 handlers pretty 
negligible.  This is easy to fix, and I'll try to get that in before 6.0.

(2) Time taken to attach 31 handlers.
  Not showing up as a problem at all.  The 31 handlers all share 31 prototypes 
that contain pre-constructed masks.  Initialization is fast.  The fix I 
suggested in (1) will decrease this time further, since the event handlers will 
become much smaller.  Note that the handlers are C++ code, and they delay JS 
compilation until and actual match/invocation of the handler, so you don't take 
any hit for compiling JS during the installation time.  In addition, the 
handlers attached to the textfield use a special shorthand syntax for command 
execution that keeps you entirely in C++.  There are no JS XBL handlers attached 
to textfields.

(3) Typing speed.
The XBL handlers are fast as hell because of the numerous recent optimizations 
I've already made to them.  They don't even show up on my profile runs involving 
textfield typing speed.  Matching a handler is done using pre-constructed 
hashes, and so no string compares or copies are required.  It's all integer 
compares.

On the topic of typing speed, the real problem is XUL.

What does show up is the XUL key listener at a frightening 25% of the time to 
process key presses.  This is much more of a problem for typing performance, and 
it is clearly the problem to focus on, not an XBL optimization that would only 
provide a minor savings for 6.0.

I am retracting my nsbeta3 nomination.

Comment 4

[David Hyatt]

I should clarify what I mean by prototype handlers in case it wasn't clear.  All 
instances of a textfield share the same prototype handlers, so even though there 
are 31 handlers per textfield, they're all lightweight and reference a single 
set of 31 prototypes that are shared by all textfields on a given page.

Comment 5

[David Hyatt]

Hehehe. Ok, I did find a profile run that can get the installation of the event 
handlers on the radar, but it's morse's pathological 400 textfields on a single 
page test case.  Even on that page, it isn't that bad, and I'll make atoms out 
of the event name member variables, which should take care of it.

Comment 6

[David Hyatt]

Futuring.  The bloat reduction I mentioned has been checked in.

Comment 7

[David Hyatt]

Not needed.  XBL event handlers are down to 28 bytes apiece, and current
profiles show that they simply aren't a problem (even when there are 30+ on the
same element).

Fast enough.