Closed Bug 584299 Opened 12 years ago Closed 12 years ago
Inline (again) string constructors and destructors
We took these out of line to reduce codesize, and performance was a wash on our macrobenchmarks. Inlining them wins us 10% on getAttribute microbenchmarks nowadays.... which means in practice around 25ns per call to getAttribute on my hardware. The ifdefs aren't pretty; I didn't have any better ideas, though.
Attachment #462700 - Flags: review?(benjamin)
Summary: Inline (again) string constructors and destructors → [FIX]Inline (again) string constructors and destructors
Comment on attachment 462700 [details] [diff] [review] Like so remove the GCC 3.3 workaround: I'd prefer to break OS/2 than to have ifdefed constructor styles.
Attachment #462700 - Flags: review?(benjamin) → review-
Comment on attachment 462865 [details] [diff] [review] OK, with that change Gah, ok. We can get rid of the ifdefs as soon as we require libxul (which will be soon after branch). File a followup, please.
Attachment #462865 - Flags: review?(benjamin) → review+
Is it possible to make further savings by moving the destructor so that classes such as nsDependentString that don't need it, don't have one?
In the current string code, nsDependentString is really only a constructor and not a useful static type, I think; I don't recall anything that prevents one from being assigned-to.
How would libxul let us get rid of the ifdefs? We'd still need to add more includes for that ctor body to compile, right?
Summary: [FIX]Inline (again) string constructors and destructors → Inline (again) string constructors and destructors
Whiteboard: [need approval]
Yes, and I'm perfectly fine with that.
Ah, ok. Gotcha.
Filed bug 584726.
Whiteboard: [need approval] → [need landing]
Pushed http://hg.mozilla.org/mozilla-central/rev/48a78e198bfd Seems to give a .5-1% codesize increase and 1-3% overall Dromaeo performance win.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b4
You need to log in before you can comment on or make changes to this bug.