profile and fix innappropriate string inlining

RESOLVED FIXED in mozilla0.9

Status

()

Core
String
P3
critical
RESOLVED FIXED
18 years ago
17 years ago

People

(Reporter: Chris Waterson, Assigned: Scott Collins)

Tracking

({embed, memory-footprint})

Trunk
mozilla0.9
x86
Linux
embed, memory-footprint
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
...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.)
(Reporter)

Comment 1

18 years ago
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)
(Reporter)

Comment 2

18 years ago
Created attachment 8975 [details]
per-DLL bloat information
(Reporter)

Comment 3

18 years ago
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.
(Assignee)

Comment 4

18 years ago
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
(Assignee)

Comment 5

18 years ago
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

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

what do you mean by analysis ?

(Assignee)

Comment 7

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

Updated

18 years ago
Keywords: embed, footprint

Updated

18 years ago
QA Contact: leger → kandrot
(Assignee)

Updated

18 years ago
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
(Assignee)

Updated

18 years ago
Component: XPCOM → String
(Assignee)

Updated

18 years ago
Depends on: 70090
(Assignee)

Updated

18 years ago
No longer depends on: 70090
(Assignee)

Updated

18 years ago
Blocks: 70090
(Assignee)

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9
(Assignee)

Comment 8

17 years ago
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.