aboutsummaryrefslogtreecommitdiff
path: root/source/am/starmath
diff options
context:
space:
mode:
authorChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2020-02-11 19:03:21 +0100
committerChristian Lohmaier <lohmaier+LibreOffice@googlemail.com>2020-02-11 19:16:30 +0100
commit614eb3429622290c320d137cfa9d8b908c56f9ab (patch)
treee5a7cd968f01648337f30b2eac4b1fe153e63c43 /source/am/starmath
parent37a6f521ec6303193d6057736ff414ef7c62c6d4 (diff)
update translations for master
and force-fix errors using pocheck Change-Id: Ib8c90ab28e150c029e92a9621e65cf00ebba33c6
Diffstat (limited to 'source/am/starmath')
-rw-r--r--source/am/starmath/messages.po10
1 files changed, 2 insertions, 8 deletions
diff --git a/source/am/starmath/messages.po b/source/am/starmath/messages.po
index 38b08a033cc..1d969022614 100644
--- a/source/am/starmath/messages.po
+++ b/source/am/starmath/messages.po
@@ -3,7 +3,7 @@ msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: https://bugs.libreoffice.org/enter_bug.cgi?product=LibreOffice&bug_status=UNCONFIRMED&component=UI\n"
-"POT-Creation-Date: 2019-11-05 14:29+0100\n"
+"POT-Creation-Date: 2020-02-10 17:54+0100\n"
"PO-Revision-Date: 2019-07-20 17:27+0000\n"
"Last-Translator: Samson B <sambelet@yahoo.com>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
@@ -2398,14 +2398,8 @@ msgctxt "catalogdialog|symbolname"
msgid "Unknown"
msgstr "ያልታወቀ"
-#. CQ8AG
-#: starmath/uiconfig/smath/ui/dockingelements.ui:10
-msgctxt "dockingelements|DockingElements"
-msgid "Elements"
-msgstr "አካሎች"
-
#. P3rFo
-#: starmath/uiconfig/smath/ui/dockingelements.ui:27
+#: starmath/uiconfig/smath/ui/dockingelements.ui:16
msgctxt "dockingelements|ElementCategories|tooltip_text"
msgid "Element categories"
msgstr "የ አካሎች ምድብ"
generated by cgit (git 2.34.1) at 2025-01-15 10:26:28 +0000
on value='libreoffice-24-8-2'>libreoffice-24-8-2 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sc/source/filter/oox/sheetdatabuffer.cxx
AgeCommit message (Collapse)Author
2024-07-18make ScRange single-arg constructor explicitNoel Grandin
Change-Id: Ie24e1e601b639dd62dbb8a201378a970699b20ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170686 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-17loplugin:ostr in sc/../filterNoel Grandin
Change-Id: I3c986d9e7f9780f08653131205626471ac75896f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167759 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-14tdf#48140: Remove unused headers from xlsx importseturaj
Change-Id: I14fad4ccd06fe9c3340646efcf80e9209cbb1dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163962 Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2023-12-28Decouple ScPatternAttr from SfxItemPoolArmin Le Grand (allotropia)
ScPatternAttr is traditionally derived from SfxPoolItem (or better: SfxSetItem) and held in the ScDocumentPool as Item. This is only because of 'using' the 'poolable' functionality of the Item/ItemSet/ItemPool mechanism. Lots of hacks were added to sc and Item/ItemSet/ ItemPool to make that 'work' which shows already that this relationship is not optimal. It uses DirectPutItemInPool/DirectRemoveItemFromPool to do so, also with massive overhead to do that (and with not much success). The RefCnt in the SfxPoolItem that is used for this never worked reliably, so the SfxItemPool was (ab)used as garbage collector (all Items added and never removed get deleted at last for good when the Pool goes down). For this reasons and to be able to further get ItemSets modernized I changed this. I did two big changes here: (1) No longer derive ScPatternAttr from SfxItemSet/ SfxSetItem, no longer hold as SfxPoolItem (2) Add tooling to reliably control the lifetime of ScPatternAttr instances and ther uniqueness/ reusage for memory reasons It is now a regular non-derived class. The SfxItemSet formally derived from SfxSetItem is now a member. The RefCnt is now also a member (so independent from size/data type of SfxPoolItem). All in all it's pretty much the same size as before. To support handling it I created a CellAttributeHelper that is at/owned by ScDocument and takes over tooling to handle the ScPatternAttr. It supports to guarantee the uniqueness of incarnated ScPatternAttr instances for a ScDocument by providing helpers like registerAndCheck and doUnregister. It hosts the default CellAttribute/ ScPatternAttr. That default handling was anyways not using the standard default-handling of Items/Pools. I adapted whole SC to use that mainly by replacing calls to DirectPutItemInPool with registerAndCheck and DirectRemoveItemFromPool with doUnregister, BUT: This was not sufficient, the RefCnt kept to be broken. For that reason I decided to also do (2) in this change: I added a CellAttributeHolder that owns/regulates the lifetime of a single ScPatternAttr. Originally it also contained the CellAttributeHolder, but after some thoughts I decided that this is not needed - if there is no ScPatternAttr set, no CellAttributeHolder is needed for safe cleanup at destruction of the helper. So I moved/added the CellAttributeHolder to ScPatternAttr where it belongs more naturally anyways. The big plus is that CellAttributeHolder is just one ptr, so not bigger than having a simple ScPatternAttr*. That way, e.g. ScAttrEntry in ScAttrArray did not 'grow' at all. In principle all places where a ScPatternAttr* is used can now be replaced by using a CellAttributeHolder, except for construction. It is capable to be initialized with either ScPatternAttr instances from the heap (it creates a copy that then gets RefCounted) or allocated (it supports ownership change at construction time). Note that ScAttrEntry started to get more a C++ class in that change, it has a constructor. I did not change the SCROW member, but that should also be done. Also made registerAndCheck/doUnregister private in CellAttributeHelper and exclusively used by CellAttributeHolder. That way the RefCnt works, and a lot of code gets much simpler (check ScItemPoolCache, it's now straightforward) and safer and ~ScPatternAttr() uses now a hard assert(!isRegistered()); which shows that RefCnt works now (the 1st time?). There can be done more (see ToDo section below) but I myself will concentrate on getting ItemSets forward. This decoupling makes both involved mechanisms more safe, less complex and more stable. It also opens up possibilities to further optimize ScPatternAttr in SC without further hacking Item/ItemSet/ItemPool stuff. NOTE: ScPatternAttr *should* be renamed to 'CellAttribute' which describes what it is. The experiencd devs may know what it does, but it is a hindrance for understanding for attacting new devs. I already used now names like CellAttributeHelper/CellAttributeHolder etc., but abstained from renaming ScPatternAttr, see ToDo list below. SfxItemSet discussion: ScPatternAttr still contains a SfxItemSet, or better, a SfxSetItem. For that reason it still depends on access to an SfxItemPool (so there is acces in CellAttributeHelper). This is in principle not needed - no Item (in the range [ATTR_PATTERN_START .. ATTR_PATTERN_END]) needs that. In principle ScPatternAttr could now do it's own handling of those needed Items, however this might be done (linear array, hash-by-WhichID, ...). The Items get translated to and from this to the rest of the office anyways. Note that *merging* of SfxItemSets is *still* needed what means to have WhichID slots in SfxItemState::DONTCARE, see note in ScPatternAttr::ScPatternAttr about that. And there is also the Surrogates stuff which would have to be checked. The other extreme is to use SfxItemSet *more*, e.g. directly derive from SfxItemSet what would make stuff easier, maybe even get back to using the 'regular' Items like all office, I doubt that that would be much slower, so why...? Also possible is to remove that range of Items exclusively used by ScPatternAttr from ScDocumentPool *completely* and create an own Pool for them, owned by CellAttributeHelper. That Pool might even be static global, so all SC Docs could share all those Items - maybe even the ScPatternAttr themselves (except the default per document). That would remove the dependency of ScPatternAttr from a Pool completely. ToDo-List: - rename ScPatternAttr to CellAttribute or similar - use SfxItemSetFixed with range [ATTR_PATTERN_START .. ATTR_PATTERN_END] instead of regular SfxItemSet (if the copy-construtor works now...?) - maybe create own/separate Pool for exclusive Items - make ScAttrEntry more a C++ class by moving SCROW to the private section, add get/set methods and adapt SC Had to add some more usages of CellAttributeHolder to the SC Sort mechanism, there were situations where the sorted ScPatternAttr were replaced in the Table, but the 'sorted' ones were just ScPatternAttr*, thus deleting the valid ones in the Table already. Using CellAttributeHolder makes this safe, too. Added a small, one-entry cache to CellAttributeHelper to buffer the last found buffered ScPattrnAttr. It has a HitRate of ca. 5-6% and brings the UnitTest testSheetCellRangeProperties from 0m48,710s to 0m37,556s. Not too massive, but erery bit counts :-) Also shows that after that change optimizations in the now split functionality is possible and easy. Change-Id: I268a7b2a943ce5ddfe3c75b5e648c0f6b0cedb85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161244 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-24use more concrete UNO in scNoel Grandin
Change-Id: I20f0200a4ed74b32b67b740e0084dae9620c2912 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159871 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-11-07ITEM: Get away from classic 'poolable' Item flagArmin Le Grand (allotropia)
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>
2023-08-28Shared string shouldn't account preserve space propertyParis Oplopoios
XLSX documents opened in Excel don't seem to account for the xml:space="preserve" value for whether the string is single line or not The test that was changed seems to have more accurate behavior now, where the second cell does not have multiple lines (like in Excel) Change-Id: Iad8f351c19102249e2cb1e1d063c8690dfb3d753 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156206 Tested-by: Jenkins Reviewed-by: Paris Oplopoios <parisoplop@gmail.com>
2023-06-22sc: filter: excel: import cell multi-line textHenry Castro
The excel document, if the cell has multi-line text and the property wrap text is off, the paragraphs are rendered all in a single line. Signed-off-by: Henry Castro <hcastro@collabora.com> Change-Id: I3b5c82dde2616887e51ad6e3dfe91d100482f747 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148004 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153470 Tested-by: Jenkins
2023-06-17sc: perf: speedup sheets with lots of repetitive...Dennis Francis
row styles using a small cache of already allocated patterns that are tied to extended format id and number format id. Change-Id: I3136aef9a034635924f7b7b6d2432f9ae5c2bd15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152692 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 92b13ad1f1a87393cf66a35694f3e542db57f150) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152874 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-05sort row-range-stylesNoel Grandin
which reduces the amount of data-movement we do in the following loop when inserting into the sorted_vector. Shaves 2% off the load time of a large document with lots of styles. Change-Id: I8df4cc35edcc212613068af108b136c2d5acd219 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152600 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-05remove span data storage from oox importNoel Grandin
We are not using it, and removing it reduces peak memory load from 648M to 548M when loading a large spreadsheet Change-Id: I683bfba6c8f151d8845bbd7d5f92cde2a9c17807 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136825 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-12fix up order of some ScDocument functionsLuboš Luňák
For better or worse the usual order of arguments in Calc is SCCOL, SCROW, SCTAB, so make this consistent. Change-Id: Ie63c75f5ae92f82cb757c0873f7ff569f331e0df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134229 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-19handle broken row ranges in excel import, #2Luboš Luňák
In ad1f6e62298612f4b277708b813a219ba390f1b0 I didn't add a second std::unique() pass, that seems to be necessary with some broken documents as well (sc_column3_regroupformulacells_heap_buffer_overflow.sample from crashtesting). Change-Id: I6865085a9b77fe51246180e519bf1a2309615144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131834 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-15handle broken row ranges in excel importLuboš Luňák
LIBREOFFICE-39G76603.xlsx from crashtesting has broken data cause assertion failures about the ranges being sorted (because the ranges overlap and StyleRowRangeComp needs and assumes that they do not). Changing the std::unique() call to remove ranges that compare equal (which is not the same as being equal, due to how StyleRowRangeComp compares) and sorting again seems to drop all problematic ranges. (I'm not adding the problematic file to tests as loading it takes a lot of time.) Change-Id: If6ac94959a649a641d02fd703d33edddbdf0fb85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131637 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-15fix comparison operators in Excel export, #2Luboš Luňák
It turns out that the end-vs-start comparison was intentional and the file causing problems is broken, so more or less revert 83d599fd7c530d14f70ac60bd673b66640191bf7, and I'll handle the problematic file in another commit. Change-Id: I5c7538a7c3eeea9c5fd1661e1a9a2c3370b799c9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131636 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-11load ods/xlsx with full row attributes without allocating all columnsLuboš Luňák
If there's e.g. an entire row bold, it's enough to set default attribute for unallocated columns. This also reverts the workaround from commit 297ab561c6754, as it's no longer necessary. Change-Id: I0b208709aeaff1c0d59da2410926876715cfe642 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131320 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-03-07faster bulk insert into o3tl::sorted_vector (tdf#117366)Luboš Luňák
Repeated insert() into o3tl::sorted_vector can turn out to be pathological, repeatedly moving most items aside for each element inserted. Make it possible to insert a normal vector that's been pre-sorted and made unique. 31s->9s for loading tdf#117366. Change-Id: If3a0366dd240ad46c23f5f3dc04e781b8c4b2aa2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131085 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-02-18clear ScDocumentImport position cache if iterators are invalidCaolán McNamara
SheetDataBuffer::finalizeArrayFormula calls ScCellRangeObj::setArrayTokens ScDocFunc::EnterMatrix ScDocument::InsertMatrixFormula and InsertMatrixFormula calls the variant of ScColumn::SetFormulaCell which doesn't take a sc::ColumnBlockPosition& param when SetFormulaCell adds a cell to the column so any iterators belonging to ScDocumentImport are invalid. Change-Id: Ic2814ecbeafdeb99632d2a255ed6c1dedf7376b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129991 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2021-10-14use std::vector::insert instead of push_backNoel Grandin
because it will pre-allocate space and often is optimised to memcpy Change-Id: I03ed7915f2762d3d27e378638052a47a28bbf096 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123588 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-16avoid a map lookup on a hot pathNoel Grandin
Change-Id: I4e514c7212c0b349796f3791b4c7f3f06d3fa22a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119064 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-03fix use-after-freeNoel Grandin
after commit deac5c84732c3491a0ef5bf7f8c1552e6def4fc0 tdf#79049 speed up OOXML workbook load (2) when updating the iterator, I forgot to update the variable we are using to point into the vector. Rather just use the iterator to access the element. Change-Id: Iac8b6b7cdd945b2ccd261b0edc2ea8a563a10b1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115028 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-30tdf#79049 speed up OOXML workbook load (2)Noel Grandin
the allocation of memory and pointer chasing was slowing things down in the styles conversion. So switch to more cache-dense data structure, and re-arrange the loops to be more cache friendly. The takes the time from 1m9 to 40s for me. Change-Id: I876580adc7823313b0cdb067f2f6b3e61c39ecf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114941 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>