| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Id7f54dd27a33cb4979e4d2594002ace25e65b34f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177441
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
|
|
for large complex documents with lots of shapes.
When that happens, we spend a lot of time scanning the std::unordered_set inside DefaultItemInstanceManager.
Since most of our items are already capable of being hashed, and thus avoiding the scanning cost, make it so we can use the HashableItemInstanceManager most of the time.
Change-Id: I43f4c04e956d316c976bea67d1941529d2d91182
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170813
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Tested-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
for the ItemInstanceManager the identification was done
using typeid/hash_code, but that has problems - it is
only defined to be identical for two instances of the
same type, but other types can have the same code.
Thanks to Noel to find that out, that is not reliable
to be used.
In the meantime we have SfxItemType to identify Item
instances, so I changed the code to use that.
The master had five additionally added Items that
use the (2a) method of this mechanism (see comments
in svl/source/items/globalpool.cxx for that). The
gloal is to use as less as possible of this Items in
that mechanism, so I checked.
For four of these hashing was used, so the mem/runtime
aspect is okay -> access is fast enough to prefer
mem over runtime. Adding hashed Items (or any other
fast mechanism) is always okay.
One did not have that (SvxBoxItem) and used just the
fallback ItemInstanceManager, so I removed it. We
now have 18 Items for which that mechanism is
initialized immediately.
Noel also already moved the countdown for starting
to use the mechanism in case of default handling
(case (1), NUMBER_OF_UNSHARED_INSTANCES) to the
unorderd_set. someting I had already planned to do,
too - thanks!
Change-Id: Icf6f427e5ea64672f385357aaad75bb5b7fcbf98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170314
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
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>
|
|
Change-Id: Ia0e95e0dd82e28f155ddf79c48832a9e0ddc3d98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170024
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I08e9ee6016ca0d67be76b0a04e7205e6d90bb46e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170023
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I16426008dd8983d56a49b3334b3f163ec350be0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170057
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
after commit 85fd526fc681a994415bb422090d1d23aa7d54f6
"fix and simplify the ItemInstanceManager mechanism"
The problem is that some *Item classes in sw/ and sc/
share WhichIds, and a whole bunch of SfxBoolItem
subclasses share the same SfxItemType enum value.
So we ended up mixing and matching objects
of different concrete subclasses in a given
*ItemManager collection.
Add some asserts to the global pool code to catch
issues like this earlier on.
Add unique value of the SfxItemType enum for all
the SfxBoolItem subclasses
Change-Id: I3c8d4e02be1cd412b0292e973a6498df5f8e7102
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170003
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib5752f1301c95d3941ecacac13918184dfe7c945
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169935
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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
|
|
Change-Id: I91365c844370ef423630d5679cadd91cbf0597b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169799
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
