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.