Description: After Dependent trace on cell into a table with about 37,000 cells with formulae in most cells, any operation on the workbook becomes exceedingly slow, taking about 40 seconds. Saving and restarting LO does not help. Rebooting the computer does not help. There was ZERO problem with No other LO application that is open functions either. I'm sorry I can't provide an example at this time as the data is proprietary. Steps to Reproduce: 1. As above 2. 3. Actual Results: LO Calc is DOA for 45 seconds on ANY edit Expected Results: Quickly be able to enter formulae Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.6.2 (X86_64) / LibreOffice Community Build ID: 729c5bfe710f5eb71ed3bbde9e06a6065e9c6c5d CPU threads: 20; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
How do you expect anyone can verify your comment. Please attach a sample file.
How do I ensure that it's open to the whole world?
I've been working on this file for months. The data is proprietary. In all likelihood, recreating the file may not show the issue. I've submitted bugs that are still unresolved years later, but the files are available for anyone on the planet with a login to access. I'll gladly submit the file to a secure location not available to everyone with an account.
Created attachment 203151 [details] file with problem Problem file attached. Seems to me the Trace function adds a boatload to the file and does not clear properly when dealing with a large number of cells. Cell AB2 Traced dependents. File takes ≈45s to open or enter any formula. Addition worksheets removed. Makes no difference. File was about 110k larger than previous day saved backup.
Well, disable the dependencies. Do you really need to work with them enabled? There are thousands of dependencies, which makes for a difficult display. Perhaps there could be a limit on the number of dependencies displayed? BTW, there is an intensive use of INDIRECT(), that is a volatile function, that is recalculated every time a cell is change, precedent or not. As example: AD27 = =INDEX($A:$ZZ;$AC27;5) I'm not sure if it is really a bug.
When it corrupts the file making it unusable, it's a problem. It happens when trace dependency is used into a single column of 1600 entries. !!!! THIS DID NOT HAPPEN IN PREVIOUS RELEASE 25.2.2.X !!!!
Additionally, if a CLEAR trace is executed, while LO is attempting to show the traces, it's all over but the crying. LO should put up an hourglass while tracing and disable additional TRACE options until complete. The whole point of being able to trace is to find dependent / sources when things don't go as expected. My current workbook as about 500,000 cells and it's by far from the largest. 200,000 cells can depend on a single cell. If I have multiple documents open, they are all toast. This is far more serious than NORMAL.
A suggestion: Rather than drawing an arrow for every cell in a dependent / precedent array, how about ONE arrow and a box around the dest / source cells? Would likely be several orders of magnitude faster.
(In reply to Ian Eales from comment #6) > When it corrupts the file making it unusable, it's a problem. > > It happens when trace dependency is used into a single column of 1600 > entries. > > > !!!! THIS DID NOT HAPPEN IN PREVIOUS RELEASE 25.2.2.X !!!! If this was referring to the opening time, then it's not true. I tested attachment 203151 [details] with several versions and the opening time has not regressed. Tested by launching from the command line with time OOO_EXIT_POST_STARTUP=1
Created attachment 205137 [details] Perf flamegraph of file opening Flamegraph of opening attachment 203151 [details] Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 4ca7291c939aaaf44ab8d7a9b0da8d407875a97a CPU threads: 8; OS: Linux 6.18; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
Changing version to 7.0 as that was the earliest I tested the file opening time with.
It's not the opening time, it's the time to show dependencies.
Created attachment 205233 [details] Perf flamegraph of tracing dependents Flamegraph of doing Tools - Detective - Show Dependents while in cell AB2 of attachment 203151 [details] Arch Linux 64-bit Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 3466a602ed80663cbe7982425219e64504b3eb75 CPU threads: 8; OS: Linux 6.18; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 27 January 2026
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7c539ecc3892f854d48fd33daffae8886fca3aee tdf#168696 speedup trace dependants It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3eb70aae778d23799f53aac1fc76baaf9f1c42e6 tdf#168696 speed up hit testing a little on polygons It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I agree that we need a better strategy for drawing arrows when the numbers get high, probably merging destinations into a bounding box and having one arrow per destination bounding box would be good. Doing that might be suitable as a G-Soc or similar project, it is mostly contained to one or two files in writer, and does not touch large amounts of our internal API.
(In reply to Noel Grandin from comment #16) > I agree that we need a better strategy for drawing arrows when the numbers > get high, probably merging destinations into a bounding box and having one > arrow per destination bounding box would be good. > > Doing that might be suitable as a G-Soc or similar project, it is mostly > contained to one or two files in writer, and does not touch large amounts of > our internal API. Created bug 170570 and alerted UX.