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


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

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.