To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=85782
                 Issue #|85782
                 Summary|there are a number of PLT/function bindings that we're
                        | not saving on startup
               Component|Word processor
                 Version|OOo 2.3.1
                Platform|All
                     URL|http://www.gnome.org/~michael/activity.html
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|code
             Assigned to|mmeeks
             Reported by|utomo99





------- Additional comments from [EMAIL PROTECTED] Fri Feb  1 05:11:35 +0000 
2008 -------
quoted:

poking at relocations on writer start (from LD_DEBUG=bindings output): 
variant            startup bindings
current                 91300
-Bsymbolic-functions    63600
-Bsym + vtrelocs        58100

Clearly there are a number of PLT/function bindings that we're not saving on 
startup. Browsing the remaining relocations I was rather amused to find 2400 
relocations on startup (4%) are to please a cunning 31337 'memory-saving' 
strategy: the thinking goes like this: 
Instead of having lots of small strings in-line in several libraries, lets have 
a single copy of each string in a common library (svtools). [ so far, so clever
 ]. 
Lets implement that using a symbol per string eg.
extern SVT_DLLPUBLIC sal_Char const SVTOOLS_CONSTASCII_DECL( sHTML_S_aacute, 
"aacute" );
[ oh dear ! - this of course generates a nice const char * rodata string - but 
it also generates another string in the svtools symbol table: "sHTML_S_aacute", 
plus another string in -each- shared library that refers to it ]. 
So - comparing to the approach of using a simple in-line string (also 
uniquified by any decent compiler & put in rodata), we loose size: ( sizeof 
"sHTML_S_" + sizeof (relocation) ) * ( num-references + 1 ) and we loose 
performance: 2400 unique named relocations, searched across 50+ shared 
libraries: ~0.8% of OO.o CPU time on startup. And all in the name of 
efficiency. Unfortunately, the technique dates back to the dawn of time, (in 
cvs history terms), so it's hard to discern the intention. I wonder where else 
it's used. 

Anyhow, the 'best' fix (to save the optimisation) is to export one symbol, 
s_HTML_Strings that is an enumerated array of strings 
#define sHTML_S_aacute s_HTML_Strings[eHTML_S_aAcute]
type thing. But for now, some search/replace action is perhaps easier.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to