| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Ib09a5331dfd57a99852555348c46730368d8d61d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100531
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found while looking for problems in another patch.
This will become more important with "jumbo sheets" when using the wrong
datatype can mean overflow
Change-Id: I7370ffd8a6edc33a5e613242735e4c7b9eaf830d
Reviewed-on: https://gerrit.libreoffice.org/83991
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
for NFIndexAndFmtType that initializes all its members appropriately.
Change-Id: Iec675458bca169c79b3a27f775ccff5265cee22d
Reviewed-on: https://gerrit.libreoffice.org/81004
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
if in cpu-threaded mode so that we can avoid the unnecessary
locked SvNumberFormatter::GetType() calls (Mapping between NF index
and NF-type does not change while formula-group-threading
is running).
Change-Id: I648bc08c885da845f0b09cd57013cc1c23e01a61
Reviewed-on: https://gerrit.libreoffice.org/80848
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
and reuse them for interpret'ing all cells under the
respective threads. This gives a sizeable win in the execution
time especially for long formula-groups.
Change-Id: Ib340950f21e863b5b821d20c092214d8bc5012aa
Reviewed-on: https://gerrit.libreoffice.org/80845
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Just before about to thread a FG, look to left and right for
"mutually" independent FG's with some restrictions and thread
this group of FG's together treating it as a single but longer
computation load.
For now the restrictions are :-
All formula-groups in a FG "group" must have :-
1. Same length
2. Same relative position.
3. Same weight.
This is very helpful in cases similar to the below :
There are lots of (say 32) consecutive formula-groups
all with same "small" length (say 8) and same weight.
By conventional formula-group-threading the speed-up is
limited to 8x even if we have a 256 core processor, but
with this threading-multiple-formula-groups patch
(in this case) we can get a speed-up of 256x provided
we have a >= 256 core machine. So effectively with this
patch the speed-up is now only limited to the number of
cells in a range consisting of mutually indepdendent
formula-groups rather than number of cells in each
formula-group.
Change-Id: Ib25b5abbb583fa207e8befff9a908d14313f3d51
Reviewed-on: https://gerrit.libreoffice.org/79485
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
ScDocument dtor calls ClearLookupCaches(), which calls GetNonThreadedContext().
But ScDocument instances used for copy&paste GetFormatTable() fails
on null mxPoolHelper, because ScDocument ctor doesn't set it in such a case.
So set up the pointer in ScInterpreterContext on demand only if actually
needed.
Change-Id: If3811da5bb00a2d7d404c089ee1bf46037a2cddb
Reviewed-on: https://gerrit.libreoffice.org/68350
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
This is necessary to fix a non-debug build failure :
https://ci.libreoffice.org//job/lo_tb_master_mac/27264/consoleFull#283816981d107d11c-eea5-4209-baa1-fcfb59f7f8a6
Change-Id: Ic4882a155dc3a8ea84129ddefe8076693787271c
Reviewed-on: https://gerrit.libreoffice.org/63402
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
used in ScInterpreter::IterateParameterIfs(). Store this
cache as a member of ScInterpreterContext (maConditions).
Create a static pool of ScInterpreterContext's so that
the embedded maConditions is reused everytime a formula-group/
formula-cell is calculated. There needs to be two separate
static pools - one for threading, one for non-threaded
computation of formula-cells. With this, we can have better
performance of the cached maConditions as well as
mScLookupCache. In threaded case there is no recursive
computation of cells as dependencies are all pre-computed.
The thread-indexed lookup cache array in ScDocument is
removed as now the lookup caches on context lives as long
in the static context pools.
This cached vConditions array can take advantage
when there are lots of SUMIFS/COUNTIFS with arguments of
similar dimensions in the document. Otherwise it will be
allocated from scratch for every COUNTIFS/SUMIFS formula-cell.
Change-Id: I654b05e55035ce6efcf07d32d36623c9d76b0ff6
Reviewed-on: https://gerrit.libreoffice.org/63066
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Found with bin/find-unneeded-includes after recent improvements
- remove UNO headers from blacklist
- remove newly found unneeded fw declarations
- fix up some not self contained headers
Change-Id: I605656bc98a64640a78d2ff4de9c7c37326033cf
Reviewed-on: https://gerrit.libreoffice.org/62264
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
There is mutex protection needed for accessing the same SvtBroadcaster
when calling StartListeningArea(). Also some of the memory management
and caching needed fixing.
Change-Id: Ia57ed85286cf195521719cfd3b320f73a6342bb1
Reviewed-on: https://gerrit.libreoffice.org/61187
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
As it modifies ScAttrArray, which is not thread-safe (has std::vector
per each column, so multiple threads may try resize it etc.). So if
threaded calculation is done, delay the calls to the main thread.
Change-Id: I3d87665c0dd0d40f0c2efbcf8958240ee5580233
Reviewed-on: https://gerrit.libreoffice.org/55602
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
|
|
which is a new header file introduced in calc formulagroup threading
work.
Change-Id: I8203ce392b36581f64457edb52449df3e84fb216
Reviewed-on: https://gerrit.libreoffice.org/45080
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
...from ScInterpreter and in the s/w interpreter, create
a ScInterpreterContext for each thread for passing into
per thread ScInterpreter constructor.
Change-Id: I4e0abce043c7e1e70859efb2e5001fc284f416a9
|
|
Possibly later things that need to be thread-local can be handled through
the ScInterpreterContext.
Why handle some thread-local things through the
ScDocument::maNonThreaded and ScDocument::maThreadSpecific mechanism,
and others through this ScInterpreterContext? Good question.
Share SvNumberFormatter across worker threads
and use mutex to protect SvNumberFormatter::IsNumberFormat()
Change-Id: I372e5fbd9a19785f55f0faf4a4bedc5fc1ef3e03
|
