Age | Commit message (Collapse) | Author |
|
Intead of gathering all possible formats just to check one..
Change-Id: I80f3a2c957492c9f72084c69b867aaccfbdd0530
|
|
Added check for availability of the SotClipboardFormatId::STRING_TSVC
that could be used instead of SotClipboardFormatId::STRING.
Change-Id: I03de4500affb71270b501b12c14287037cea7c3c
Reviewed-on: https://gerrit.libreoffice.org/44975
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ia773da1fb1c0af0855321ce88c488a5b86c7cf92
|
|
Change-Id: I18c281211e6eeb4816da13972c360df85d577491
|
|
In preparation for adding a new enum value to keep existing
formatting in any case.
Change-Id: Ic15a900adba0281d1267d95f821e1e898f80f566
|
|
Change-Id: I6e30bd1b77f0f7df01571c9f497cbde1380e73be
|
|
...from ScInterpreter and in the s/w interpreter, create
a ScInterpreterContext for each thread for passing into
per thread ScInterpreter constructor.
Change-Id: I4e0abce043c7e1e70859efb2e5001fc284f416a9
|
|
If the exisiting token is of wrong type, create and use a fresh new
token instead.
Change-Id: I348b0972306497dfe7eae0655c9b93d5830cb740
|
|
Change-Id: Ic0b4dff6f03ef3f88bd150e798fa2d83dfb0f486
|
|
Change-Id: Iacc93122191152183127500a4172358a14e96c8b
|
|
added hasHyperThreading() function to tools::cpuid
to detect hyperthreading.
Change-Id: I13fab4b6c649e681c329b7e3f4c9f36bda879d84
|
|
Allocate ScTokenArray object only once per worker thread, fill it
for the first row/cell and reuse them for subsequent rows/cells
if possible.
Change-Id: If8f20da618938d0e189224f189b4763815702e10
|
|
Also introduce new state
ScFormulaVectorState::FormulaVectorEnabledForThreading
to indicate that using the “traditional” vectoring is disabled,
but threading should be tried.
Change-Id: I552d9e29e1ab9e5721534e07f4a45fdd5a23f399
|
|
Change-Id: Ia1aaf40aa4e8e6f41ca190272365528bf37bf130
|
|
Change-Id: I9a2066c396802551c3eda2c8db32b6d1a4171dfd
|
|
Otherwise the aThreadedCalcBlackList check in CheckToken() has no
effect, we would still attempt the threaded code path.
Change-Id: I08dc2dd174459615ab8a11dbb819e39fc5437d10
|
|
Change-Id: I5e37b9a8325af35a15c01409f9eaa2f92459cc28
|
|
Did not have any impact on performance, though.
Change-Id: I7e769b4a74e0ff9e0aabfb7e291fc4b987441954
|
|
Introduce a configuration setting to turn it off. For now, can also be
turned off with the environment variable SC_NO_THREADED_CALCULATION,
but that is probably not something we want to keep or guarantee
staility of. (LO looks at way too many environment variables already.)
Change-Id: I469cde259eda72cc2d630814a25f707f1210b0ab
|
|
Change-Id: I1dd679156661bb5cb025ca6cb46d19783524d5a4
|
|
Change-Id: If10c6a58f5b6f196f3644f6c592dd6d1dc0d860c
|
|
Change-Id: Ide03e0ae1fe97e1a09a767908a981a1e803a3474
|
|
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
|
|
Those are likely highly problematic to do in parallel.
Change-Id: I50cc32eb72f6b7951d247ecd787b2942cd7d9163
|
|
Change-Id: I4de0051d9fa5de9147954c6021d47076145a3e59
|
|
Change-Id: I48748434c845af963af160f8bbd75e4ab7ce95bd
|
|
Move the calls to increment and decrement it out of InterpretTail(),
to those call sites that aren't reached during parallelized
calculations. Use unique_ptr for pInt in StackCleaner
Change-Id: Ie1bd03dd62aea5f6c71c383df21afff29391dade
|
|
We can use normal thread_local data for it as a thread can only be
acting on one ScDocument in parallelized formula group calculation
anyway. Use separate data instance for the non-threaded data, and when
a thread starts, copy that to the thread-specific data.
Change-Id: I3e58320a728d1c5639a8a078748b3d4d7a451b25
|
|
This is part of the work to enable having several ScInterpreters
working on the same object in parallel. Perhaps a more thorugh
re-factoring would be better, maybe these fields should not be part of
ScDocument at all, but part of ScInterpreter?
Without this change the parallelism unit test occasionally fails.
Change-Id: I70500b4d2b513e134d22b4b98c84a3ec00dad291
|
|
Change-Id: I645630fae8a5fcd09d8af4c4ec9aac94edbd2f25
|
|
Change-Id: I9bd889523b5e5374776d94534ae2171e7a5a635d
|
|
Change-Id: I53a13bebf018c15a1d94c15adbfa7b68632c77b0
|
|
Don't just check whether we are in the "main" thread, as that is not
true in the tiled rendering unit test, for instance.
Change-Id: I4f3ca1a1b1cb3c92856104fffe8100f18cd7b66c
|
|
Change-Id: Ied03498333ee531e6e31e05fa2734056673364f2
|
|
Change-Id: I8b9a4680691d47732be2dd159ffc5d56d12a7a95
|
|
Change-Id: I7c12301f5a435dfca733b5f87b4b083f98a5292a
|
|
Change-Id: I174bca167379b96083476a394d8ff5d7f00a8021
|
|
Change-Id: I102b02e93ff06f3e53b9a1194277f5a6fae9f1ed
|
|
Might now actually do what it should.
Change-Id: Ibf38560a37910924c4fade79cbbf4553d6dbd077
|
|
|
|
And not just the number of rows in the group. This means that even
relatively short formula groups that calculate over large ranges of
cells will be eligible for parallelized calculation. The weight of a
formula group is the number of rows in the group times the weight of
the formula.
The weight of a formula is for now the number of cells referenced by
all cell ranges in the formula, divided by 10. For instance, the
weight of SUM(A1:B100) would be 20. If no cell ranges are used, the
formula's weight is one.
Change-Id: Ib77e403961d8f487d580eea6b901fa4f5e4102b0
|
|
Change-Id: I96bed3ebd90af9a8ab2c17b678384cf340ba2802
|
|
We don't do anything at the moment to check whether a formula group
calculation thread "failed", I don't even know what it actually would
mean. So just bin that code for now.
Change-Id: Ie4b15a3c20169d08d338e255a71a139913528a16
|
|
Change-Id: I2f7e6fb747b6a74172a81f9db9bc210ef6a27342
|
|
Change-Id: If968792c4b98afbe0cc956e9cab0bcfde47bf1c1
|
|
USe by adding a ScMutationGuard object to a section of code that
shouldn't be run during threaded calculation of a formula group in any
of the calculation threads. There are currently several "classes" of
mutation as bits of ScMutationGuardFlags, althouh I am not sure
whether that will be useful, so far I use just the one same (CORE) in
all cases.
Currently implemented using mutexes. Possibly a simple bool field in
ScDocument would be enough, the multiple flags and mutexes might be
over-complicating it? Maybe I misunderstood what I want.
Add such mutation guards for some fields of ScDocument.
Change-Id: If2a8223c49d36143f2984e0449798271f2b6440d
|
|
For now, formula group calculations are done in parallel threads when
1) OpenCL is not used, and 2) the environment variable
CPU_THREADED_CALCULATION is set. This commit is a surely broken first
step and does not actually work that well at all.
Change-Id: Ia7e5019703ba89bff0695faef0f7504765061149
|
|
if this isn't what we want, then presumably ScSetStringParam shouldn't
exist here at all
Change-Id: I17318c38948bc19b7148276935830f83356c7ed2
Reviewed-on: https://gerrit.libreoffice.org/45008
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Hopefully the last such commit, now that the in-gerrit verification is
in place and also a warning is printed locally for those who push
directly.
Change-Id: Ib80cbca0b29dc7f71cbb182a38ad6839a659ff41
Reviewed-on: https://gerrit.libreoffice.org/45002
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I9926d55568f8b5bbc67f448bbf7fb660e74505fd
Reviewed-on: https://gerrit.libreoffice.org/44964
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|