enhancing perfcheck - Proof of concept & proposals
lgodard.libre at laposte.net
Wed Oct 22 03:18:17 PDT 2014
First, thanks a lot for your answer
> Most of that is just loading the file - maybe we could use 'loperf' for
> testing import/export and do only the rest as perfchecks? What do you think?
I instrumented the big file load for testing purpose but yes, in
absolute, i'm also interrested in perf check of such files loading (and
i agree to keep the instrumentation as slow as possible, but in my
experience, some perf problem start to appear exponentially with file
complexity (a lot of sheets/formulas/named ranges/cell notes)
so the first idea of this big file was to gather all the potential
problems and instrument each case
>> 2- exploiting results
>> $ cat perfcheckResult.csv
>> lastCommit test name filedatetime dump comment count
>> 741c661ece19ccb4e94bb20ceb75d89a29b1b2a8 sc_perf_searchobj
>> 10/14/2014 09:54:52 testSheetFindAll - Search value 11403647297
> Fun, for me Search value is more than 10x faster - Was there some fix recently?
> 10/22/2014 08:27:58 testSheetFindAll - Search value 766042247
i work on 2 a weeks old branch
would be great if things evolved here ;-)
> Well, this is good but it's hard to parse the results quickly.
> Do you think we could have date/commit in one line with all numbers?
> And descriptions somewhere at the top.
> So that we could compare results in one column easily (and draw graphs..)
> Something like
this is what is intended to be done
the output is a tabulated separated csv file, with all the information
on a single line (and description at top)
may be a bad email layout ?
btw, i'll double check
>> 3- re use of existing tests for percheck
> So - now that I think about it.
> Maybe it would be better to stop duplicating makefiles too.
yes that would simplify the beast, providing we can start the
instrumentation (and disable it on running normal tests)
> Or - even better - we could just compile in the callgrind code all the time and decide when
> running make, whether we want to run under valgrind --tool=callgrind or not (or both).
> If that works. :-)
> So, something like IS_PERFCHECK is always true, no duplication
> and only decide whether to run under valgrind.
> Does that make sense?
> What do you think?
i like the approach as it will simplify the trickiest part (the nasty
include to avoid double linking problem)
imho, it would be clearer to keep some 'make perfcheck' command but this
- set IS_PERFCHECK
- start running callgrind
- launch all the tests with clear parts identified with the
maybe do i miss something as it is not far from the actual thing
feel free to give me some code pointers (remember, i'm only a poor
scripter, always-beginner in core stuff ;) )
Thanks a lot again matus
More information about the LibreOffice