Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


Hi,

On Thu, May 28, 2015 at 10:40:40PM +0200, Bjoern Michaelsen wrote:
And with this I see a lot of processes running parallel till the end. This
suggests to me that the stuff is quite parallelized -- however none of the
testing threads seem to be CPU-bound rather the Java-stuff seems to be IO bound
(for IPC?) with the slowest test unit taking ~5 minutes. Thus even 32 jobs or
more dont seem to keep more than one core busy.

So, I has a look at what is so slow in subsequentcheck:
sc_unoapi        4m21.137s
sw_unoapi        3m34.494s
toolkit_unoapi   3m18.056s
forms_unoapi     2m51.588s

sw_complex       1m 6.937s
framework_unoapi 1m 2.938s
svx_unoapi       0m40.205s
sd_unoapi        0m38.568s
chart2_unoapi    0m37.695s
xmloff_unoapi    0m29.696s
ucb_unoapi       0m25.288s
starmath_unoapi  0m24.856s

pragmatically splitting up the first four:

 https://gerrit.libreoffice.org/#/c/15959/

brings 'make check' down to 2m6s on big Bertha. For comparison:

 find instdir/ -name '*lo.so'|xargs rm; time make

that is, just relinking (most) LibreOffice libs takes 2m26s on that machine
without symbols (assume more than 10 minutes with symbols). Given this
relation, there is no excuse to not run 'make check' anymore at least before
pushing -- if there ever was one.

Best,

Bjoern

Context


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.