Created attachment 195117 [details] A problematic file hanging on Windows https://ask.libreoffice.org/t/compatibility-of-linux-and-windows-versions/107576/8 The attachment hangs Calc when opening it on Windows (it will open after tens of minutes). It opens instantly on Linux. The problem is data in U23:XFC23 on Exemplare sheet. Tested with: Windows (hangs): Version: 24.2.5.1 (X86_64) / LibreOffice Community Build ID: 2ccb78ad6bdfe3f3356a7a7f294ec388775c5816 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded Linux (opens fast): Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 24; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (C.UTF-8); UI: en-US Ubuntu package version: 4:24.2.4~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded
Already seen in oldest of Windows 7.5 bibisect repo even without activating support for very large spreadsheets. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e142fa40fa721bf76da09c1fdc2d32705b5f74b3 CPU threads: 2; OS: Windows 11 X86_64 (10.0 build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
In kf5 it does not open instantly (as it usually does). It takes 5-8 seconds, which is a lot more than I'm used to for a document with so few data. Deleting the data in U23:XFC23 (Exemplare sheet) "solves" the issue and the file will open instantly. Tested with Version: 24.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: d681c57ba51b635ba7c85b21e062732110e8293f CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
(In reply to Rafael Lima from comment #2) > In kf5 it does not open instantly (as it usually does). It takes 5-8 > seconds, which is a lot more than I'm used to for a document with so few > data. Compare with 25m47s on Windows (and I have Linux time of 4s on the same system). Yes, even 5-8s is "instantly" here.
My first thought was that maybe the problem was related to the wrong worksheet references, and (then) also wrong cell references. But, opening attachment 195117 [details] with LO 7.2 (which does not support 16K columns) takes only a couple of seconds on Windows. So, whether the problem is 16k columns by itself (LO 7.4+), or the accumulation of "#NAME?" and "#REF" errors, or the combination of both, the resulting behavior was not seen with older versions of LO on Windows. Therefore, I wonder whether this could be considered as a regression, and/or as implementation error, at least from the POV of the resulting behavior.
(In reply to ady from comment #4) Identifying the starting commit is useful in either case. It is definitely either a regression or an implementation error; in this case, it's more likely a regression, because it appeared before the new feature got introduced, so it was a part of *existing* functionality refactoring, which was a precondition to the new functionality.
Bibisected with win64-7.4 repo to 4c5f8ccf0a2320432b8fe91add1dcadf54d9fd58 change default Calc number of columns to 16384 (tdf#50916)