...according to news://news.mozilla.org/39266D9B.BEE5B1D3%40fateware.com This is clearly not good. Need to determine why. (At first blush, "templates!", but specifically which portions of the new template interfaces are causing the problems.)
Ok, for my own sanity's sake, I just built libraptorhtml.so with and without NEW_STRING_APIS turned on. My trees are identical: pulled at the same time 2000-05-22 8am PST. I built with the following flags: ac_add_options --with-pthreads ac_add_options --enable-tests ac_add_options --enable-pedantic ac_add_options --enable-ignore-no-long-long-warning ac_add_options --enable-optimize ac_add_options --disable-debug Here are my file sizes: NEW_STRING_APIS 6,721,707 no NEW_STRING_APIS 6,681,043 That's a difference of 40,664 bytes, or a 0.61% bloat. ramiro: where are you getting 7% from? What am I doing differently? "egcs -v" reports: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
Ok, breaking stuff down by DLL and looking at overall payload size confirms ramiro's 7% number. I've attached a table with exact stats per DLL.
I'd like to understand exactly what facet of the new string APIs is introducing the bloat, and why it varies so much from module to module. Depending on what the real cause is, there are different solutions. Templates were a good way to ensure that the APIs for wide and narrow strings were the same; but they are not vital to the correct functioning of readable and writable. I could redefine the interfaces without templates. Some portions will have to remain templatized.
Status: NEW → ASSIGNED
The most probable cause of this bloat is innappropriate inlining. This can can probably be fixed without drastic changes. More analysis is needed.
scc, i think the bloat is almost guranteed to be coming from inline abuse. what do you mean by analysis ?
I mean looking at the generated code to see which functions _shouldn't_ be inlined.
Summary: NEW_STRING_APIS cause ~7% text size bloat on egcs-1.1.2 → profile and fix innappropriate string inlining
Target Milestone: --- → mozilla0.9.1
Well, most of the templates are gone now. I think we'll be handling any remaining |inline|-ing decisions on a case-by-case basis as part of other performance investigations and when things crop up in the string tests. I'm closing this bug now. If you (any reader that is) has any specific performance problems related to strings, we should file a bug on that particular problem.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.