I haven't profiled any of the editor/keytyping stuff, but code in nsXULKeyListener seems like an obvious candidate for replacing nsString usage with nsIAtoms (or at worst, nsAutoStrings for automatic variables).
Actually, I'm replacing most of that string crap with booleans. What is the advantage to an nsIAtom?
An "atom" is a string that has been hashed to a unique value. Everytime you ask for the same string, you get back the same atom. So, this is a big win if you do a lot of string comparison: you can atomize the stings you routinely compare against, and do a single pointer compare with "==" instead of a strcmp().
Oh, it is a flyweight. Why must we think of new names for everything?
Atom tables have been around since people started writing compiles, methinks. :-)
Eh... OK. You win.
Regardless of how long the term "atom" has been in use (quite a while, not that it matters), for things like "true" and "false" it makes sense just to convert to booleans inside the key listener code (though it wouldn't hurt to use atoms for those boolean values when initially parsing the code). No particular reason to store atoms representing a string when all it does is codify a boolean value ...
Booleans are the plan
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Converted to nsAutoStrings, and fewer of them. May go back and make them atoms later.
Assigning to originator per new organizational structure.
Changing QA Contact back to email@example.com
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: paulmac → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.