7d8196ea2f
There were over 150 places in *::Notify() functions that did some dynamic_cast<SfxSimpleHint*> of which ~98% were unnecessary because the base class SfxHint passed was an SfxSimpleHint anyway. dynamic_cast operations come with quite some cost, so avoid if possible. Specifically for ScFormulaCell::Notify() that created a bottleneck in scenarios where cells were notified that already handled a previous notification. In mass operations doing the dynamic_cast before it could be decided whether having to act on it or not this made 2/3 of all time spent in the Notify() call. To get rid of that rename/move SfxSimpleHint to SfxHint and let classes derive from SfxHint instead of SfxSimpleHint. This comes only with a slight cost that an additional sal_uInt32 is transported in such hints, initialized to 0, but this is neglectable compared to the huge gain. For the rare cases where a Notify() actually expects both, an SfxHint (formerly SfxSimpleHint) and a derived hint, this changed order of the dynamic_cast involved so the simple SfxHint::GetId() is handled last. Modules using such combinations can further optimize by treating the simple SfxHint::GetId() first once verified that none of the other derived hints use an ID not equal to zero respectively none of the ID values the simple hint uses. Change-Id: I9fcf723e3a4487ceb92336189d23a62c344cf0ce Reviewed-on: https://gerrit.libreoffice.org/29205 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com> |
||
---|---|---|
.. | ||
inc/pch | ||
qa | ||
source | ||
unx | ||
util | ||
AllLangResTarget_svl.mk | ||
CppunitTest_svl_inetcontenttype.mk | ||
CppunitTest_svl_itempool.mk | ||
CppunitTest_svl_items.mk | ||
CppunitTest_svl_lngmisc.mk | ||
CppunitTest_svl_notify.mk | ||
CppunitTest_svl_qa_cppunit.mk | ||
CppunitTest_svl_urihelper.mk | ||
JunitTest_svl_complex.mk | ||
Library_fsstorage.mk | ||
Library_passwordcontainer.mk | ||
Library_svl.mk | ||
Makefile | ||
Module_svl.mk | ||
README |
Contains non-graphical helper code for office applications. Specifically this module does not depend on or use includes from module vcl. Originally all code in svtools that did not depend on vcl was split off into this svl ("svtools light") module. In particular the SfxItemSet is a property-bag like container that stores arbitrary sets of properties for everything from text run formats, to Chart regression line properties. There are lots of other useful helpers in here for various office tasks; much of this code was originally moved from svx/sfx2. == Items, Pools and Sets == === SfxPoolItem === A small reference counted piece of data. Many subclasses, each with a unique integer to identify its type (WhichId). Can be compared for equality (operator==), Clone()d, and converted to/from uno::Any (QueryValue/PutValue). A pool item may have value semantics ("poolable"), meaning that there will generally be only one instance that compares equal per item pool, or not, in which case the item will be Clone()d quite a bit. === SfxItemPool === Usually there is one item pool per document, with a range of valid WhichIds that is specific to the type of document. The item pool owns all instances of SfxPoolItem or its subclasses that have ever been added to an item set. It also contains a default item for every WhichId, which will be (depending on parameters) returned from item sets if the set does not contain an item at this WhichId. === SfxItemSet === The item set can be created with a user-supplied range of WhichIds; it will accept SfxPoolItems with matching WhichIds and ignore attempts to insert items with non-matching WhichIds. Items that are successfully inserted into the set will be stored in the set's SfxItemPool, and for poolable items only a single instance that compares equal under the predicate operator== will be stored in the pool, regardless of how many sets contain it, thus conserving memory. There are members m_pWhichRanges for the valid ranges (as pairs of WhichIds), m_nCount for the number of items contained, and m_pItems for the pointers to the actual items.