summaryrefslogtreecommitdiff
path: root/helpcompiler
ModeNameSize
-rw-r--r--Executable_HelpIndexer.mk695logplain
-rw-r--r--Executable_HelpLinker.mk811logplain
-rw-r--r--IwyuFilter_helpcompiler.yaml675logplain
-rw-r--r--Library_helplinker.mk1251logplain
-rw-r--r--Makefile478logplain
-rw-r--r--Module_helpcompiler.mk703logplain
d---------inc131logplain
d---------source399logplain
generated by cgit (git 2.34.1) at 2025-01-23 04:34:42 +0000
TW. I guess these have to be fixed before thinking about this change... Good news is that all 11 cases were the same in SW, in SwHistorySetAttrSet::SwHistorySetAttrSet which does some strange things using two SfxItemIter in parallel. Thus SW UTs are also clear and I see no more errors caused by ItemSets being changed while SfxItemIters are alive. Bad news is that I still have errors to hunt... NOTE: Have now cleaned all UTs, this showed that there are some unexpected side-effects of the Items being processed in another order when SfxItemIter is used, also found one case where a WhichRangesContainer is constructed for a SfxItemSet using the set items from another ItemSet and SfxItemIter to do so. There *might* be more cases not covered by UTs. NOTE: While speed stays the same and mem is reduced up to 25% (see measurements in 1st comment) another *important* aspect is that this frees the way for using ItemSets *without* WhichRanges - these are necessary mainly to create that fixed array of pointers to the Items in a *manageable* size. With a dynamic structure like unordered_set there is in principle *no need* anymore to use WhichRanges to pre-define the Items a Set could hold. There is one exception: We have cases where one ItemSet is set at another one with defined WhichRanges to *filter* the contained Items - these would have to be identified. This is a rare case and we would have to check cases where an ItemSet gets set at another ItemSet. This would be as if all ItemSets would be AllItemSets in principle - much easier for everyone. NOTE: Waited for 24.8 split just to not take unnecessary risks. Change-Id: I75b0ac1d8a4495a3ee93c1117bdf618702785990 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166972 Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> Tested-by: Jenkins 2023-08-07ITEM: speedup WhichRanges access by bufferingArmin Le Grand (allotropia) I checked for was to speedup SfxItemSet stuff, so had (besides other things) a look at WhichRangesContainer and it's usage(s). Problem with the WhichRanges is that a WhichID which you try to find is usually inside that range, so binary search is no option. You have to detect in which range the WhichID is hosted and can the directly calculate the index into the array of Items at the SfxtemSet. Currently when needing to transform a WhichID to an index into the array of Items in SfxItemSet the array of the WhichRangesContainer is searched linearly from the start every time. This can be a little bit speed up by buffering the last successful 'hit' and trying to re-use it. Also the special case of a single WhichPair (e.g. UI stuff) is worth having a look. All acesses to that transformation are changed to use the tooling method getOffsetFromWhich() at the WhichRangesContainer which does the transformation. This also needed cleanup of ItemOffsetHint instances & stuff around it. It does not more than before but also profits from the single entry buffer. I added some DBG_UTIL-based stuff to watch the hit/miss ratio, which is heavily changing from app to app & usage, but varies around 1.5 to 3.5, also saw 6.5 and more at document import. NOTE: I already checked if sorting the WhichPair(s) in WhichRangesContainer by their 'width' (highest WhichID mnius lowest WhichID helps. The idea was when the Items would be used in a regular manner that when having the widest WhichPairs at the start, the buffer would even be better used - but doing tests in all apps shows nearly no gain, so I left that out. NOTE: Not too much speedup, but faster... Had to deep-debug due to CppunitTest_sw_odfexport failing, found a slight diff between GetItemState impls, corrected. Also added more changes, e.g. TotalCount is now a member to not always have to calculate it from the WhichRangesContainer. Extended GetWhichByPos to 1st try to find a set Item, else iterate over WhichRangesContainer. This is due to SfxItemIter's implementations of GetItemState and ClearItem which both up to now just accessed the SfxPoolItem array of the SfxItemSet, ignoring that no Item (nullptr) or state DONTCARE (-1) may have been set there (no item is prevented by ite Iterator, but better be careful). Added WhichRangesContainer::getWhichFromOffset and made SfxItemSet::GetWhichByOffset use it. Addedd optimizations there for single-entry WhichPair and using the buffer at WhichRangesContainer which is possible. Removed debug comparing stuff (had a test that used the former adapted GetItemStateImpl method in SfxItemSet::GetItemState and compared with the changed GetItemState_ForWhichID). Added some comments and assertions where useful. Made ClearSingleItem_ForOffset work without handing over WhichID, that makes calls using it simpler and avoids calculating the WhichID just for that call. Change-Id: I54de552368b654f00f115978715f8241eb603752 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155316 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2022-05-28add ClearItem to the SfxItemSet iteratorsNoel Grandin 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> 2022-05-28add GetItemState to SfxItemIter, the same way I did to SfxWhichIterNoel Grandin 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> 2022-03-11new loplugin:trivialdestructorNoel Grandin 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> 2021-09-20introduce SfxItemSetFixed and use it in DefaultPropertiesNoel Grandin DefaultProperties::SetObjectItemSet is very hot when loading shapes, and a large chunk of that cost is allocating the pool item array. So use a template class to allocate the array in-line to the class, which means it can be allocated on-stack. Change-Id: Ic53b41f35784726362de38fceb35f8634cddf0a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122310 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-11-16tdf#123936 Formatting files in module svl with clang-formatPhilipp Hofer Change-Id: Iaaac34428ef0e5b8f09f6cbcad16ea5bab145321 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105714 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2019-10-01Avoid redundant IsAtEnd: NextItem returns nullptr iif iterator is at endMike Kaganski To keep the check efficient, split NextItem to inline and Impl parts Change-Id: Id5877a3c5bed73aac9c39c655b106a715cf888ea Reviewed-on: https://gerrit.libreoffice.org/79894 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2019-09-30Simplify iterating in SwRegHistory::MakeSetWhichIds a littleMike Kaganski The IsAtEnd check is redundant here. Change-Id: Ie576d039ea3db5f98d9c8c3dfd7e77519fcc1e1d Reviewed-on: https://gerrit.libreoffice.org/79836 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2019-06-07tdf#42949 Fix IWYU warnings in svl/Gabor Kelemen Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Except source/svdde/* which is WIN-specific Also recheck include/svl Change-Id: I32d3bcb6b14665c56c07a2f10526329b08c64cbe Reviewed-on: https://gerrit.libreoffice.org/73630 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2018-09-19svl: fix SfxItemIter on empty item setMichael Stahl The problem is that IsAtEnd { return m_nCurrent == m_nEnd; } is never true because of the odd initialisation with m_nEnd > m_nStart. Change-Id: I477b0f111e2c2f47fe093800710a9b28ca8a5925 2018-01-11loplugin:useuniqueptr in svlNoel Grandin Change-Id: I2fdb63517349474d90cb17ad2bd667f30840e83d Reviewed-on: https://gerrit.libreoffice.org/47727 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>