| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reverts commit 85fd526fc681a994415bb422090d1d23aa7d54f6.
Change-Id: I5019f72f88497f50a77666d57f2d16c2749bd1c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170218
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The mechanism is currently broken because it uses hash values as keys,
in two different places. But hash values are not required to be unique,
and as soon as there are enough items of a given type, a collision is
inevitable.
So just simplify this whole mechanism. There is no reason we need
type-specific item managers. Stuff everything into a single global pool,
that uses hashing correctly.
Notes
(*) Performance, as far as I can tell, is the same or slightly better.
(*) I removed the NUMBER_OF_UNSHARED_INSTANCES thing, in favour
of just having a simpler mechanism
Change-Id: I9068baf9bf6fae2500ae5748c6d1aabe6c3a18a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169709
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
|
|
The task shows that the commit including the Item
paradigm change has follow-ups: It now does no
longer try to share Items as much as possible
(detailed reasons in that commit). Mainly for speed
reasons since that sharing was done before by
(mostly) linearly searching in existing instances
registered at one Pool, using the operator== of the
SfxPoolItems. That costs runtime.
There is somewhere a sweet-spot between memory and
runtime: the number of Items allocated and the time
spent to share them more effectively. This task shows
- despite being a non-real-world document - that
for extremes like this putting work in sharing is
still needed.
But there are possibilities to combine both: If we
can implement solutions that do not need much time
to ideintify an aleady existing instance we will get
the best of both worlds.
As explained already in that change, if we would
need that again, then on a better base. Thus I drove
forward ITEM changes to a state where we are now able
to share Items globally in the office - not per pool
but for all ItemSets/ItemHolders and thus all Apps/
Models/opened documents.
NOTE: This currently needs to include the WhichID
that is included in the Item, so cannot share pure
Item-data (as the old usage did too). This does not
need to stay that way: If you think about it, the
association between WhichID and Pool/Holder is
defined in Pool/Holder, so theoretically the Item
does not need to contain the WhichID. This will
be hard to do due too many places in the code that
use the WhichID stored at the Item.
To support that I added an ItemInstanceManager with
a simple interface (find/add/remove) and it's usage
in the two central Item-existance managing methods
implCreateItemEntry/implCleanupItemEntry. The
interface is pure virtual and all methods private,
only the mentioned managing methods are allowed to
access these. Also added a virtual method to
SfxPoolItem called getItemInstanceManager() that
can be implemented by Items that want to support
that.
Also added a default implementation of
ItemInstanceManager called DefaultItemInstanceManager
that uses linear search using operator== from the
Item that can be used/added to every Item easily.
It works for all Items and does in principle what
the former implementation does. It is intended as
simple/fast fallback.
I also added a statistic element to measure the most
used non-RefCounted Items on an Office-run, this
will be printed at office shutdown using SAL_LOG
and the 'svl.items' flag.
I then checked all Items that were used in this
error/bug scenario that used an extensive number
of incarnations and added an ItemInstanceManager
for these.
For SvxFontItem I added one that creates a hash and
thus needs not to search for instances at all, with
the caveat that the WhichID needs to be included.
Thus the hash is not at the Item, but only in the
ItemInstanceManager implementation.
For SfxBoolItem I implemented one that hashes using
the WhichID and holding both possible states in an
associated std::pair, true and false, thus the
SfxBoolItem is identified fast and only two instances
per WhichID exist (when used in Pool/Holder).
For 11 other Items I just added using the standard
implementation, DefaultItemInstanceManager. Of
course the more we optimize the better it will get.
For all Items where I added that mechanism I also
added ASSERT_CHANGE_REFCOUNTED_ITEM to all write
calls/methods for that Item. It asserts when the
RefCounted Item is to be changed. This should be
done in all write accesses to Items, but we have
ca. 500 derivations.
NOTE: There was *one* place I found where that
was already done -> was alredy seen as problem,
but not really adressed.
Despite this example file is not representative,
it is still a start to init this new instance
re-use of Items.
I am already thinking about doing that globally,
depending on the usage number (maybe combined with
sizeof(item)). There is no argument to not even
change strategy at runtime when a specific number
of incarnations of one Item derivation is reached,
but this is not part of this fix.
Change-Id: Ie56cf40e0341f98dcbf29cf5c06368316829415e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162402
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
To understand this, some look back in history will be needed to see
why it is as it is today. In some (reworked) comments 'poolable' is
described as flag to hold Items in the ItemPool, also always having
only one incarnation of each possible Item.
This is not the original intention, but a side-effect. The reason is
what the binary format in the office did: To save a document, the
Objects & the Pool were saved, *not* individual Items *together*
with the objects. The Pool was completely (binary) saved (and loaded)
in one run.
Temporary IDs were used to represent at the objects in file which
Items were referenced. This *required* to have only one incarnation
per item to have a minimal binary file size, thus this high effort
was put into this. At doc load, the pool was loaded, all Items were
set to RefCount 5000, the references from the objects were restored
and then for each Item the RefCount was lowered by 5000 again
and - if being zero - deleted. Items for UI were marked 'non-poolable'
to *not* safe them with the document, so poolable was a flag to decide
if that Info/Item was to be saved with the document - or more direct:
if it is Model Data.
Items are small, so if we prefer runtime it is okay to no longer being
strict with this, anyways does not happen often and has only marginal
memory effects - compared to runtime effects/savings.
Other problems which this caused: One example is that objects in the
UNDO stack were still in the pool, so e.g. deleted pictures were saved
with the document despite no longer being used (!). That is the reason
we have an UndoItemPool and a method MigrateItemPool to move stuff to
that Pool when objects go to the UNDO stack - all of this is also no
longer needed.
Cleaning this up means to ideally have all items in the SfxItemSet,
no longer at the Pool. The Pool should be reduced to a 'Default-Item-
Holder' and a 'Slot-to-whichId-mapper'.
This needs thorough cleanups/removals, but will be worth it because
that massive simplification(s) will increase safety an runtime and make
migrating to the goal of completely type-based ItemSet stuff easier for
the future. Hopefully only view code in the office working with items
will have to be changed for this.
In this 1st step I already found that some 'compromizes' will be
needed:
- There are still Items that have to be at the pool to make the
Surrogate-stuff working. This gives back all Items in a Pool of a type
and is used in ca. 80 cases. Each one looks at these Items *without*
context (e.g. a SfxItemSet at an Object would be a context), so if e.g.
a dialog is open that temporarily uses Items of that type you would
also get these - without knowing about it...
To make that work there is still a mechanism to have Items at the Pool,
but now just *registering* (and un-reg) them without any sort/search/
remove needs. Also only for Items that need that, so I evaluated the
GetItemSurrogates calls and added some asserts when GetItemSurrogates
tries to access an unregistered item type which needs to be added.
- Another caveat is that there are about 250 places that directly put
Items to the Pool (not all remove these, that is done at pool deletion,
so some kind of silent 'garbage-collection' is in place). To have an
overview I renamed the accessing methods to separate them from the same
functionality at the SfxItemSet, which had the same names. An
implementation does still add these directly to the pool, there is no
way to cleanup those usages for now. In principle all these should be
changed to hold the data at an SfxItemSet.
I am still hunting problems. But you can build the office, all apps
work (including chart) and you can do speed comparisons already.
There are test throwing errors, so I hunt these now. It is hard to
give an estimation about how much more changes/corrections will be
needed.
Completed adaptions to new registered Items at Pool, that reduces the
failing tests. Still many that I need to hunt.
Added stuff to work around that 'compromize' in ScDocumentPool: It
overloads ::PutImpl of the pool to implement special handling for
a single Item in SC, the ScPatternAttr. In former code that method
was used from SfxItemSet and ::PutImpl at the pool directly, so it
was only used in one place. I am not sure if it was used from
the SfxItemSet functionality, but better offer it for now. To not
waste too much runtime the callbacks depend on the boolean
'NewItemCallback' at the SfxPoolItem, it gets set for that single
Item in SC and only then the callbacks trigger. I hope to get rid
of those again, e.g. newItem_UseDirect is only needed since we have
no 'real' StaticPoolDefaults currently - another thing that needs to
be cleaned up in a next step.
Since usages of impl(Create|Cleanup)ItemEntry and
Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to
unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it
globally available in svl and use it also directly for
Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing
tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that
fallback (e.g. tryToGetEqualItem) was used before, thus this is the
same class of errors (SfxPoolItem ptr-compare) as the others which I
will need to find anyways. Also fixed some missing stuff.
Have now idenified and redirected all SfxPoolItem ptr-compares
to be able to debug these - one cause for the remaining errors is
probably that before with bPoolable those often were sufficient, but
are no longer. Used the [loplugin:itemcompare] and a local clang
build to do so, see https://gerrit.libreoffice.org/c/core/+/157172
Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter
to implCreateItemEntry to signal that it gets called from DirectPool
stuff - currently needed. Hopefully when getting rid of that DirectPool
stuff we can remove that again
Added two more debug functionalities:
- Added a SerialNumber to allow targeted debugging for deterministic
cases
- Added registering & listing of still-allocated SfxPoolItems at
office shutdown
Found PtrComp error in thints.cxx - POC, thanks to
areSfxPoolItemPtrsEqual. Will hopefully help more with other tests
Found some wrong asserts/warnings where I was too careful and not
finding something/succeeding is OK, fixes some UnitTests for SC
For SC I now just tried to replace all areSfxPoolItemPtrsEqual with
the full-ptr-content compare SfxPoolItem::areSame. I also needed to
experiment/adapt the newItem_Callback solution but got it working.
Did that replacement now for SW too, found some places where the
direct ptr compare is OK.
Continued for the rest of occurrences, now all 160 places evaluated.
Also done some cleanups.
Massive cleanups of stuff no longer needed with this paradigm change.
Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now.
It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that
already needs many exceptions. Also useful for testing if errors
come up on this change to test if it is related to this.
Added forwarding of target Pool for ::Clone in SvxSetItem and
SvxSetItem, simplified SfxStateCache::SetState_Impl and returned
to simple ptr compares in SfxPoolItem::areSame to not do the test
in areSfxPoolItemPtrsEqual.
Debugged through UITest_calc_tests9 and found that in tdf133629
where BoxStyle is applied to fully selected empty calc the Item-
reuse fallback has to be used not only for ATTR_PATTERN, see
comment @implCreateItemEntry. Maybe more...
Problem with test_tdf156611_insert_hyperlink_like_excel. Found that
in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField
is found and returned as ptr, but it's usage crashes. That is due to
the SfxItemSet aEditSet used there gets destroyed at function return
what again deletes the SvxFieldItem that is holding the SvxURLField
that gets returned.
This shows a more general problem: There is no 'SfxPoolItemHolder'
that safely holds a single SfxPoolItem - like a SfxItemSet for a
single Item (if Items would be shared_ptrs, that would be a safe
return value).
That will be needed in the future, but for now use another solution:
Since I see no reason why EE_FEATURE_FIELD should not be shareable
I wil change this for ow in the SfxItemInfo for EditCharAttribField.
That way the Item returned will be shared (RefCnt > 1) and thus not
be deleted.
I changed the return value for GetURLField() and
GetFirstURLFieldFromCell() in ScEditShell: At least for
GetFirstURLFieldFromCell the return type/value was not safe: The
SvxFieldItem accessed there and held in the local temporary
SfxItemSet may be deleted with it, so return value can be
corrupted/deleted. To avoid that, return a Clone of SvxFieldData
as a unique_ptr.
With all that UnitTest debugging and hunting and to get the paradigm
change working to no longer rely on shared/pooled items I lost a
little bit focus on speed, so I made an optimization round for the
two central methods implCreateItemEntry/implCleanupItemEntry to
get back to the speed improvements that I detected when starting this
change. It was mainly lost due to that 'strange' chained pool stuff
we have, so I added to detect the target pool (the one at which the
WhichID is registered) directly and only once. Next thing to cleanup
will/should be the pool and it's concept, all this is not needed
and really costs runtime.
Since implCreateItemEntry/implCleanupItemEntry are executed millions
of times, each cycle counts here.
Had an error in the last changes: pool::*_Impl methods use index
instead of WhichID - most of them. Another bad trap, I really need
to cleanup pool stuff next.
Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
make SvxWeightItem sortable, which shaves off 1%
and turn the tree search off while performing this operation, which
shaves off about 25% of the time on my machine.
Change-Id: I94358ed565a0d9f1cc0ddb36b8349e83c9deb959
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95369
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and can then remove some casting
Change-Id: Id821c32ca2cbcdb7f57ef7a5fa1960042e630ffc
Reviewed-on: https://gerrit.libreoffice.org/85022
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie9da2c57fa9cd355dc5826cf5afd1c5b84cd22d7
Reviewed-on: https://gerrit.libreoffice.org/81648
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(1) Migrated all still existing binary load/save stuff
in SfxPoolItem to legacy files. Isolated from Item
implementations. Adapted all usages. No more methods
Create/Store needed, also GetVersion removed
(2) Removed operator= for SfxPoolItem. Adapted all
usages. Goal ist to handle Items more as Objects
('Object-Oriented') in the sense to move/handle
instances, not to copy one instance over another one
(which is more and more problematic with hard to copy
content as UNO API stuff or similar). This lead to
much more usages of std::shared_ptr which correlates
well with future plans fr Items (see dev branch).
Next logic step will be to also remove copy constructor
Linux build and corrections done
Fixed Writer test and removed unused defines
Fixed another unused m,acro
Started to unify the AutoFormat stuff
Changes to OUString constructor usages, tests completely
No idea why, but SfxStringItem constructor which
takes a OUString& now insists of not getting ::OUString's
handed in - changed all 'SfxStringItem.*OUString.*".*"'
accordingly
Change-Id: Ibed7358b18fb019994a7490332b9d797a6694c29
Reviewed-on: https://gerrit.libreoffice.org/71075
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ic14d2e66434817bcb7bd1e2b707f81d720d596b6
Reviewed-on: https://gerrit.libreoffice.org/71007
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
this is the single biggest chunk of stuff my upcoming paramtypedef
loplugin will warn about, so do it separately
Change-Id: I412e69e76406d6d947101885d4cd92c65e021508
Reviewed-on: https://gerrit.libreoffice.org/68486
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I98f49765c6b74808dcbd692e0f375dd2848fcfd4
Reviewed-on: https://gerrit.libreoffice.org/65614
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ib1a45e69736beb034c1e99e8e0fcb10aef9ffb70
Reviewed-on: https://gerrit.libreoffice.org/63405
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...in SfxPoolItem-derived classes that have a user-provided copy assignment op
(to override the explicitly deleted one of SfxPoolItem, cf.
727878a7d8ae25342db75173cc314fa330ccc077 "Remove unused copy assignment ops of
SfxPoolItem-derived classes"), so GCC 9 would warn about the implicitly-defined
copy ctor. Mark all those with "SfxPoolItem copy function dichotomy" comments
so they can be found again should the odd design of SfxPoolItem ever be changed.
Change-Id: If206716747c42205ae4822a3f54c9de037c75286
Reviewed-on: https://gerrit.libreoffice.org/58172
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic044a6e4568e707022d87bc5712205fbdf084ba2
Reviewed-on: https://gerrit.libreoffice.org/52067
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I expect a lot of the overriding methods will be removed as soon as I
run the unusedmethods plugin
Change-Id: I4fb228724fcfba51a98d2113efb93cec1bc15c7c
Reviewed-on: https://gerrit.libreoffice.org/52006
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which requires explicitly adding null in
1) SdrItemBrowserControl::SetAttributes(const SfxItemSet* pSet, const SfxItemSet* p2ndSet)
where SdrItemBrowserControl is only used by SdrItemBrowser and the only use of that is
within DBG_UTIL in SdrPaintView
2) SwCursorShell::GetContentAtPos( const Point& rPt,
within a #ifdef DBG_UTIL block in
3) SvxSearchDialog::BuildAttrText_Impl( OUString& rStr,
bool bSrchFlag ) const
where the other branch uses SvxResId
4) SfxPoolItem::dumpAsXml(xmlTextWriterPtr pWriter) const
5) XFillStyleItem::dumpAsXml(xmlTextWriterPtr pWriter) const
looks very much like all uses (outside the dumpers) are intended
to be in the ui locale
results in that INetContentTypes::GetPresentation always called with UI Locale
Change-Id: I5a110c107838b4db3c355476426d6532f2b6ce52
Reviewed-on: https://gerrit.libreoffice.org/40538
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and drop the SvxChartTextOrientItem class, unused.
Change-Id: I99100837d1beb953450f57b2cda47d165df1620c
Reviewed-on: https://gerrit.libreoffice.org/34747
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and
coverity#705367 Mixing enum types
coverity#705371 Mixing enum types
coverity#982694 Mixing enum types
coverity#1027717 Mixing enum types
coverity#1371228 Mixing enum types
coverity#1371242 Mixing enum types
coverity#1371280 Mixing enum types
coverity#1371310 Mixing enum types
MapUnit and SfxMapUnit share the same values and
are freely cast from one to the other.
Now that
commit d30a4298bdb5ba53cd1fe659f2b742f218a2e527
Date: Thu Aug 11 15:02:19 2016 +0200
loplugin:unusedenumconstants in package..svtools
removed the SfxMapUnit entries that were directly unused, they
don't match anymore and casting from one to the other is dangerous.
Why there was two of these anyway escapes me, get rid of SfxMapUnit
and just use MapUnit universally
Change-Id: I4db5dcd04b59be2f85b62b728f96c90afe00c57e
Reviewed-on: https://gerrit.libreoffice.org/28234
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
tools/rtti.hxx removed
completed the interface of some Sdr.* Items
and removed pseudo items
Change-Id: I0cdcd01494be35b97a27d5985aa908affa96048a
Reviewed-on: https://gerrit.libreoffice.org/19837
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
|
|
Change-Id: I9fe00eef7ddcd4a3c87e497a8d62f98e71a0d6d8
|
|
Change-Id: I2a46f2128ef86ea0d692240b968ea52ab8e09dcc
Reviewed-on: https://gerrit.libreoffice.org/19489
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
more useful to make it explicit.
Specifically, otherwise my defaultvalue clang plugin would want to
remove lots of places that contains #define constants which, while
technically the same as the default value, convey semantic
information which is quite useful.
Change-Id: I918ad5b0e73ba279fa1b1489b62d900339ff71eb
|
|
Change-Id: I15b2be5a9cd6e72447b674a65eabe9f89cb6ff12
Reviewed-on: https://gerrit.libreoffice.org/17115
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
The primary benefit of this is that it's no longer necessary to manually
downcast to each and every subclass in sw.
Change-Id: I5742d5744836eef192eef2d4f7ad180da67eb914
|
|
Change-Id: I97ccc04190b1f75c54e725e0612724a2ef62fe3e
|
|
since all two of the actual call-sites only care about whether
it is a valid presentation or not, not what kind of presentation it is.
Change-Id: I75717c88878d37b2897741b0c833ff283b3fee59
|
|
Change-Id: I45dfd2429a490af3cc80f51340e0c05a91425668
|
|
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
|
|
...where the latter contains SAL_OVERRIDE annotations
Change-Id: Id64794b388d83dfe7026440e8b20a5b5efd412d1
|
|
Change-Id: Ic31455a1f5ffffa35d4fdde901dd70734207b6f4
|
|
...and SfxEnumItemInterface::HasBoolValue, too.
Change-Id: Ia032e3d35a4c3b4c1efdc515ca36e466be03fc0a
|
|
Change-Id: I5a172bb12b62940b9994b2740e054b43145b08f0
|
|
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
|
