[Libreoffice-commits] core.git: include/svl sc/source solenv/gdb svl/qa svl/source svx/source sw/source

Eike Rathke erack at redhat.com
Fri Jan 20 18:30:24 UTC 2017


Hi Noel,

On Tuesday, 2017-01-17 08:08:08 +0000, Noel Grandin wrote:

> commit 2757ee9fe610e253e4ccc37423fa420004d0f388
> Author: Noel Grandin <noel.grandin at collabora.co.uk>
> Date:   Mon Jan 9 10:27:22 2017 +0200
> 
>     used std::map in SfxItemSet
>     
>     instead of naked array

I suspect that introduced some performance drawback, which can be seen
as spikes of some tests at
http://perf.libreoffice.org/perf_html/suite_calc.html if the spike
occurs on Jan-17, for example in
http://perf.libreoffice.org/perf_html/tdf100709_load_of_calc_on_vm139.details.html
drilling into 30 days
http://perf.libreoffice.org/perf_html/tdf100709_load_of_calc_on_vm139.r30.details.html
and unchecking all but Ir, Cest and Runtime, the commit before the jump
with Ir: 6,537,893,256  is
https://cgit.freedesktop.org/libreoffice/core/log/?id=98397a48f1f33be3405b0f462fc20422f6363b68
and after the jump with Ir: 7,379,267,469  is
https://cgit.freedesktop.org/libreoffice/core/log/?id=a3bb39324e5e2cff2699e830454358ac1597ffff
in which span is commit 2757ee9fe610e253e4ccc37423fa420004d0f388

Could you check if there are optimizations possible now that std::map is used?

Thanks
  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20170120/b1440d84/attachment.sig>


More information about the LibreOffice mailing list