Hi Noel, On Tuesday, 2017-01-17 08:08:08 +0000, Noel Grandin wrote:
> commit 2757ee9fe610e253e4ccc37423fa420004d0f388 > Author: Noel Grandin <noel.gran...@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
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
