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.
--
Lubos Lunak
l.lunak@suse.cz
Context
- Re: Automatic using ::rtl::OUString etc. (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.