namespace / typing thrash ...
l.lunak at suse.cz
Mon Apr 16 09:23:07 PDT 2012
On Monday 16 of April 2012, Michael Meeks wrote:
> Oh - and finally (Lubos) I pushed an item to the ESC agenda to discuss
> whether we should be exposing tons of classes and their symbols in the
> product, just to make unit tests work :-)
I assume this is about 69d46dd7a6adfffd71da055bb65108c80d27395f .
My motivation for the change was limiting the size of the debug build, which
is so huge that just writing and reading those .o files takes a noticeable
time. It is made even worse by the fact that make+gbuild order build commands
so that allmost all compiles go first and linking goes last, which means all
those .o's get written, then the early .o's get evicted from caches (even on
a 12G RAM machine), then linking starts, which first reads those early .o's
again and evicts later .o's, which then get read again. Just this I/O shuffle
is 20% of my full build time. So I now usually build with workdir/+solver/ in
zram, where it fits, but it still costs me 6G RAM. But those huge unittests
libs weren't a happy sight in general anyway (e.g. Petr has had already
failed LO builds in the buildservice because of them being too large).
And it's not exactly tons of symbols, and even before my change there were
many symbols selectively made exported, so I assumed that the tests used to
work this way already before and had gotten broken e.g. by the gbuild
conversion. I don't think there's a perfect solution. Making the release
build slower because of a debug build is kind of lame, but I don't think the
number of symbols makes any noticeable difference. Including whole copies of
sc/sd/sw libs directly into unittest libs could also make the size explode if
we get more unittests. We could possibly build debug builds with visibility
disabled and link, and build release builds with object inclusion, but I
don't know if that is worth it.
l.lunak at suse.cz
More information about the LibreOffice