Age | Commit message (Collapse) | Author |
|
to speed up operations when iterating over SfxItemSets
Change-Id: Ie40327ffaf7faa801ccc12d2b05c546a7fe49802
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135079
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
in preparation for passing a hint into it
Change-Id: Id9e5516619a314406d8250bb2145996593dafbaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135078
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
using SfxWhichIter instead of SfxItemIter
Change-Id: I046ae2cec9246b1dea9c484f94b88d64825f952c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135077
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to speed up GetItemState while iterating
Change-Id: Ibe092e7581a5be0160eed52472122afe7e0ef377
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135076
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to speed up other places that are iterating over
SfxItemSets
Change-Id: I646bae12420d15e67effdd279e071cdf8a8afffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135075
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
by having SfxWhichIter track the current position in
the m_ppItems table, which means GetItemState does
not need to traverse the ranges table to find the
item position.
shaves 75% off the time of
./instdir/program/soffice.bin --calc --convert-to pdf
~/Downloads/ofz24932-1.rtf
Change-Id: Ib5fe61c75ca05bc2f1932e84b57ccfa55f8b7f74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135023
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There is this number format:
<number:date-style style:name="N36" number:automatic-order="true">
<number:day number:style="long"/>
<number:text>.</number:text>
<number:month number:style="long"/>
<number:text>.</number:text>
<number:year number:style="long"/>
</number:date-style>
in a paragraph which has fo:language="zxx", so the field has
LANGUAGE_NONE.
MSWordExportBase::GetNumberFormat() exports as: DATE \@"dd/MM/yyyy"
But should be: DATE \@"dd.MM.yyyy"
Follow Eike's suggestion to use the number format's language in case the
field doesn't have one.
Change-Id: I596bea5daa75c717931b3c5d5506103b87b8ee08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134638
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
shaves 20% off the time of
./instdir/program/soffice.bin --calc --convert-to pdf
~/Downloads/ofz24932-1.rtf
Change-Id: I85c8bdd51895d768c37d247f6bf07ce9183d1107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135014
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
by using std::move on the newly created poolitem, so that the pool does
not need to clone it
Change-Id: Ib90b14173d19768517eb2a31cc0a105e5eb4d7c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134991
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
In file included from svl/source/misc/sharedstringpool.cxx:11:
In constructor ‘svl::SharedString::SharedString(rtl_uString*, rtl_uString*)’,
inlined from ‘svl::SharedString svl::SharedStringPool::intern(const rtl::OUString&)’ at svl/source/misc/sharedstringpool.cxx:129:51:
include/svl/sharedstring.hxx:56:20: error: ‘pResultUpper’ may be used uninitialized [-Werror=maybe-uninitialized]
56 | mpData(pData), mpDataIgnoreCase(pDataIgnoreCase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
svl/source/misc/sharedstringpool.cxx: In member function ‘svl::SharedString svl::SharedStringPool::intern(const rtl::OUString&)’:
svl/source/misc/sharedstringpool.cxx:93:33: note: ‘pResultUpper’ was declared here
93 | rtl_uString *pResultLower, *pResultUpper;
| ^~~~~~~~~~~~
Change-Id: I2171855844c76ad3b2a72c1eca737691ca96fc46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134736
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Libc++ debug has a feature that randomizes equal elements during
sort, which normally wouldn't make a difference, but some tests
rely on specific order of tested data. The ones failing without
this include:
CppunitTest_sw_ooxmlexport testMsoPosition
CppunitTest_sw_xhtmlexport testTdf66305
CppunitTest_sw_ww8export testCommentExport
Change-Id: Id49846939a264150cc82091718ffe6b904d7130e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134337
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Calc uses SharedString in mdds::multi_type_vector, which may move
contents of its blocks on some operations, and making this inline
makes such operations faster.
Change-Id: I67d14639cf253c56b8cca5b2837bb06bc9afd7d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134339
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I0a5fa033a54d8f3b8b0248cf67e252c640b33e82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133974
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
(regression from d7ba5614d90381d68f880ca7e7c5ef8bbb1b1c43)
Change-Id: I8bb9a967aefa2e88f05c23456a0dd1a090e1a5fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133932
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
ScFillSeriesDlg always expects the strings describing the start and end values
to be in the system locale. This change ensures that and fixes the bug where
using non-locale-default data in the Fill Series dialog leads to an error.
Change-Id: I25eafa2174294dc35a63473a54c529c2d7bd87ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132532
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
found by inspecting call sites of OUString::getToken
Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iefa570476bf0c881e36679ae9511ff63162e05d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133771
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
CentOS 7 system NSS defaults to legacy "dbm:" DB.
test_desktop_lib.cxx:2943:Assertion
Test name: DesktopLOKTest::testSignDocument_PEM_PDF
assertion failed
- Expression: bResult
NSS_CMSSignerInfo_Sign() (called from NSS_CMSEncoder_Finish())
internally calls PK11_FindKeyByAnyCert() and that fails likely for same
reasons as documented in previous commit.
The workaround here is a bit more involved, it turns out there's another
path with NSSCMSSignerID_SubjectKeyID where the caller can pass in a
SECKEYPrivateKey, let's try to do that as a fallback if a manual call to
find the key fails.
Change-Id: I298ee72f178220bcf644093917dba8143b092c92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133577
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I4462f7cf4740fa4d1b129d76a0775f4250f41bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133555
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I53df3f273fd5587b12c509ead1477c2108d7fe75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133456
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I114bec72cb933238675e539a8388a607226827cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I07f11bf12fbe1d1c2d812fa0965d6e632e1e1aba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133437
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3584042d0341d5c1b4f4e742e25e9eb0aa26f1da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133378
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iab8b9a802ebac60b52007754430352d3de925374
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133026
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I9b6a074eb6342808d02a69f3ed1fa713e81d2608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132958
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
for which we have o3tl:: equivalents
Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found by tweaking the loplugin:stringview and making it whitelist
getLength
Change-Id: Ic41cd4e3026d93b70a76fe1279c6de3abbe6b4a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132820
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ica4231235b0a2d32ba8558cc409b549acd887077
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132758
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
... even if the locale doesn't define such DM order or
LongDateDaySeparator.
Change-Id: I4bef720dff3582de9b60313824a84b570c153e98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132741
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
so we can use it in places where we cannot include comphelper
Change-Id: Iba0ba3e4c0dcf0f9d1f09092a77c3b2010ec4f6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132732
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I54e3ddf79ba793fd4328bf8bda7f949b65349651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132693
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
old ones default to the current all zero case and continue to work
as before
Change-Id: I6fe3b02fafcce1b5e7133e77e76a5118177d77af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131974
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Seeing as old versions of the hash may be in the users config, add a
StorageVersion field to the office config Passwords section which
defaults to 0 to indicate the old hash is in use.
Try the old varient when StorageVersion is 0. When a new encoded master
password it set write StorageVersion of 1 to indicate a new hash is in
use and use the new style when StorageVersion is 1.
Change-Id: I3174c37a5891bfc849984e0ec5c2c392b9c6e7b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131947
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I86592be0717c062a918108bf4437074b0f70b372
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132029
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
look for potentially trivial destructors that can then be elided
Change-Id: I435c251bd4291b5864c20d68f88676faac7c43fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131318
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's used only for the ConfigurationWrapper singleton, so it's used
only the first time and then ignored. It also causes calls to
comphelper::getProcessComponentContext() for every single invocation
despite the value not being needed, and the calls may not be cheap
(it's ~5% CPU during ODS save because relatively frequent calls
to officecfg::Office::Common::Save::ODF::DefaultVersion::get()).
Change-Id: I02c17a1a9cb498aeef220ddd5a0bde5523cb0ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131056
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
These classes are used extensively during some operations in Calc,
and not even LTO can inline these when they end up in different
binaries.
Change-Id: I5b17a004c6cc039508b76d557d58714c83f237a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131071
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Sorting ends tells all listeners on all the sorted cells to end
listening to stop updates, then sorts the cells and starts
listening again. This will cause all broadcasters for the sorted
cells to temporarily stop having any listeners, so they'll be
deleted and removed from the mdds vector (which may additionally
cause moving large parts of the mdds vector repeatedly). And
since all listeners will want to listen again after the sort,
this will all need to be reconstructed. To avoid this,
temporarily block this removal and then later just checks
and remove any possibly left-over broadcasters that ended up
with no listeners.
Change-Id: Ie2d41d9acd7b657cf31a445870ce7f18d28d5ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131069
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
See tdf#42949 for motivation
Change-Id: I25779cbfb1aa93c31d6e12ac95e136b3bdbbc058
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130403
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
to reduce heap allocations
Change-Id: Ia755c3e7f9610a5441a447cc74ea38ebcef068bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130066
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It doesn't make sense to have few SfxItemPool functions in a separate
source file, and without LTO those tiny functions do not get inlined,
which is confusing when profiling.
Change-Id: I0ba891ba51c7d8dd3eba3f4cae0f7819f9b033e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130327
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The LookupHashCode() way still loops over an array while calling
virtual functions for a type that is actually known. Overriding
instead a whole new Lookup() function that does the loop
avoids the virtual calls, allowing compiler optimizations such
as inlining, or class-specific optimizations like the hash code.
So this still improves performance with ScPatternAttr a bit,
for tdf#135215 it saves about 40% of load time, but this is
scraping the bottom of the barrel, as this is still a linear search
(the IsSortable() approach, if it worked, would be still 3x faster).
Change-Id: I8fe5f70cabb77e2f6619d169beee8a3b4da46213
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130228
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The function expects elements starting from smallest to the biggest,
and finds the first one that is not smaller than the one searched for.
That means that all items remaining will not be smaller, and thus
end of search is when items compare larger. Comparing remaining
items as smaller means searching until the end.
Change-Id: If5cf5c18951abf987ddbbf201f49cfb195e36d32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130220
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
speeds up loading a large chart by 5%
Change-Id: Idd8566012a0049d429e38b589782fc6d76eb3a5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130132
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to prevent object slicing.
Which reveals a problems with
commit 044fa30a4c77013c87a7e2a6dd9022a2f6599778
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Sep 23 18:44:42 2021 +0200
no need to allocate this SfxItemSet on the heap
and
commit 044fa30a4c77013c87a7e2a6dd9022a2f6599778
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Thu Sep 23 18:44:42 2021 +0200
no need to allocate this SfxItemSet on the heap
so revert the problematic bits of those commits
Change-Id: I5eeba1d5bdb91f4e539850516f2b1c11e69ff2c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130127
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(Somewhat oddly, there is no OStringBuffer::copy counterpart.)
This required some modification to StringView::VisitCXXConstructExpr to avoid
> In file included from odk/qa/checkapi/checkapi.cxx:29:
> In file included from workdir/CustomTarget/odk/allheaders/allheaders.hxx:351:
> In file included from instdir/sdk/include/rtl/math.hxx:31:
> instdir/sdk/include/rtl/ustrbuf.hxx:1687:16: error: rather than copy, pass with a view using subView() [loplugin:stringview]
> return copy( beginIndex, getLength() - beginIndex );
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
while building CppunitTest_odk_checkapi as external C++03 code, where the
returned value is wrapped in a CXXConstructExpr. And testing for that case
required a new CompilerTest_compilerplugins_clang-c++03 that uses gb_CXX03FLAGS
and needs to not set LIBO_INTERNAL_ONLY (via gb_CompilerTest_set_external_code),
as compiling as C++03 would otherwise generate lots of errors like unknown
char16_t at include/sal/types.h:118. (There was a choice whether to name the
new test "-c++03" or "-external", but the issue it tests is caused more by the
code being compiled with C++03 than by this being external code, see above.)
Change-Id: I873a9c5a70d3ea949cf13a169d46920b71282712
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130036
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As pointed out by 585e0ac43b9bd8a2f714903034e435c84ae3fc96, some
item types cannot be used as IsSortable(), because they are modified
after having been inserted in the pool, which breaks the sorted
order. But it's possible to at least somewhat improve performance
of these items by explicitly providing a hash code and using
that first for comparisons when looking up items, which may be
cheaper than calling operator==.
With ScPatternAttr such comparisons seem to take only 60% of the
original time, reducing loading time of some documents by 25%.
Change-Id: I41f4dda472fb6db066742976672f2c08b9aeef63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129667
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
REPLACE is really a replaceAndFind instead of a findAndReplace.
Thus, when you changed your search parameter and did a replace,
it replaced the previously searched for item, and then found the
first instance of the new search parameter.
That of course is just wrong.
So make sure to verify that the previous search
matches the current search competely.
However, that doesn't mean that the entire searchItem matches,
since we don't want to restart the search just
because the replace parameter changed.
In my testing, this wasn't an issue for REPLACE_ALL.
So the only time we need to worry about the last search
result is in a replace once situation.
P.S. This commit exposed that mpSearchItem can point
to a destructed SvxSearchItem, so this patches unit test
will crash if the other 7.4 commit is missing.
Change-Id: I7be14d64534018718145c6ac5f8629ff5f2e5611
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129385
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id9e18e66f3b3c583d7cb22ee0a5d6272ca2f7ea9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129556
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|