Caolan McNamara

I see that better margin notes made it onto the Google summer of code for OOo.

here’s a totally unusable little chunk of experimentation around notes which might help someone interested in this to see some of the classes that interact in this area and the sort of things that might be useful in properly implementing this.

I suggest doing it just for “normal” view, and leaving things as they are for “web layout” view. Expanding the right margin area to make room for the notes, and then using either writer frames or MultiLineEdits to implement the notes themselves, select a better yellow for the margin notes background and draw lines across the page from the margin note anchor position to the margin note, and then layout the margin notes as close to horizontal across from their anchor postion as possible, pushing them out around the anchor point into the available space if notes overlap.

I happened to notice that there was a big difference in size when compiling the sw (writer) module with different -finline-limit values. And I was messing around with that because I’m still bitter about discovering that modernizing some of OOo’s macros to templates bloated up the final size of OOo considerably and so I abandoned the effort. I wondered what sort of a difference messing around with -finline-limit might make to e.g. startup-time.

The comparison here was of simply starting a writer document containing a macro triggered on document load which printed to stdout the current timestamp and forced an exit. Hopefully an indication of how long it takes to launch OOo and get to a state where useful work can be done. What I was really interested in was getting reproducible figures which could indicate sanely if the change made a difference. Always tricky, and dropped from these results is the effect of cat-ing some huge files between runs, which just caused wild skew between runs of 7 seconds to 22 seconds, worthless data. Also dropped was the fillmem and flushdisk between runs, which also had unreliable variation. What’s installed for these runs and size comparisons was just writer and calc. The compiler is our current rawhide gcc 4.1.2-3.

Compelling is the size difference, original size of
du of 152148 for /usr/lib/openoffice.org/program
vs
du of 150392 for /usr/lib/openoffice.org/program
so nearly two megs in stripped binaries smaller. Surely that’s a good thing that has to show some run-time benefit, or not ? I’ll even take performance neutral.

All runs were over 27 iterations so that throwing out outliers would still give a reasonably large set of samples

1. on a “warm” start of simply launching OOo iteratively gives 2.53 secs vs 2.36 startup in favour of inline-limit=64
2. on a “cold-sim” start of calling michael’s cache killer inbetween gives 42.47 secs vs 39.71 in favour of inline-limit=64
3. on a “bizarro” start of launching OOo from a dvd and unmounting it in-between gives 96.76 secs vs 95.33 in favour of inline-limit=64 (yeah a minute and a half, I don’t recommend it)

And I randomly selected =64 because on fiddling with some simple code to get a feel for what the X in -finline-limit=X means 60ish seemed around what I sort of vaguely intuitively expected to be the cutoff limit for inlining before I’d really thought about it.

Full results including interesting cachegrind summaries which show better cache miss rates at in this calc document.