40125 - profile and fix innappropriate string inlining

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Chris Waterson]

...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.)

Comment 1

[Chris Waterson]

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)

Comment 2

[Chris Waterson]

Attachment: per-DLL bloat information

Comment 3

[Chris Waterson]

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.

Comment 4

[Scott Collins]

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.

Comment 5

[Scott Collins]

The most probable cause of this bloat is innappropriate inlining.  This can can 
probably be fixed without drastic changes.  More analysis is needed.

Comment 6

[Ramiro Estrugo]

scc, i think the bloat is almost guranteed to be coming from inline abuse.

what do you mean by analysis ?

Comment 7

[Scott Collins]

I mean looking at the generated code to see which functions _shouldn't_ be 
inlined.

Comment 8

[Scott Collins]

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.