enhancing perfcheck - Proof of concept & proposals

[Laurent Godard]

Hi Matus

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 
even saving)

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
> http://dev-builds.libreoffice.org/callgrind_report/history.fods
>

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 
would only
- set IS_PERFCHECK
- start running callgrind
- launch all the tests with clear parts identified with the 
start/endInstrumentation

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

Laurent