Stuff Michael Meeks is doing

Up early, J. off to the dentist, back to 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.
Spammed the suse gcc team with my patches for comment, poked at Sankar's first iogrind patch - nice. Dug at mail, investigated generating live memory snapshots for running processes, ie. a simple core-dump to run 'strings' on, to try to work out how XYZ process managed to blow up the heap so comprehensively. Unfortunately, it's not easy /proc/<pid>/mem looks like just what you want, until you try to use it - you have to pread the addresses out. Dug at cryopid for some stealable code, before giving up. Presumably manual fun and dump binary memory filename start_addr end_addr in gdb is the best that can be done easily.
Huge 24inch screen arrived, got that setup - albeit the Mobility FireGL 5200 insists on flickering when you type (or move the mouse - interesting), then got SL10.3 installed on the AMD UVC prototype, now it has it's own screen: great to get a USB image booted and a (remote) network install done in a couple of hours. Amazon ordering frenzy, bed.

variant	startup bindings
current	91300
-Bsymbolic-functions	63600
-Bsym + vtrelocs	58100

My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.

Stuff Michael Meeks is doing

2008-01-24: Thursday