https://bugs.documentfoundation.org/show_bug.cgi?id=133976
--- Comment #18 from Buovjaga <[email protected]> --- (In reply to Alexandre Sena Coelho from comment #17) > One thing I noticed — and I’m not sure if it’s relevant — is that, between > builds a9966e81381059a3a9d8fc4d391ba17d99385fee and > f23af7a56dda5aabe8ba3616566fbfe75805759f, the processing time increased > significantly. For investigating regressions, we have repositories of binaries that can be used with git bisect: https://wiki.documentfoundation.org/QA/Bibisect https://wiki.documentfoundation.org/QA/Bibisect/Linux The commits you reference are quite fresh, so probably they are not yet included in the bibisect-linux-64-25.8 repository. It is even possible to automate bisection, which can be nice for cases where something takes a long time. Here is an example for conversion time: https://wiki.documentfoundation.org/QA/Bibisect/Automation#Measuring_conversion_time However, I've found the results from such runs can be unreliable, so one should always manually test the blamed commit vs. the previous commit. The tutorial can be a kind of cheatsheet for the steps: https://wiki.documentfoundation.org/QA/Bibisect/Bibisecting_tutorial > I could try to set up a test suite to compare the performance of EPUB export > with the Fixed Layout across different builds, using a diverse set of > documents as samples. Would that be useful? I’m not sure if something like > this already exists. We do have this automated setup running callgrind: https://perf.libreoffice.org/ but I don't know much about it. The Jenkins job is https://ci.libreoffice.org/job/lo_callgrind_linux/ -- You are receiving this mail because: You are the assignee for the bug.
