I’ve turned off Skia and still very slow!
1 Like
Isn’t your question somewhat subjective?
You don’t mention what your spec of PC is or the platform on which it runs so is impossible to replicate and thus very much opinion based.
A rarely used but strikingly effective way to make such operations “very slow” is to use non-native functions (UDF) in formulas for conditional formatting of large cell ranges.
A real help with the problem will - if at all - only be possible with the help of detailed information about the system and the settings. It would be very important to know whether the problem occurs with all spreadsheets or only with certain ones. In the second case, an example is indispensable.
Sorry about that! Windows 10 AMD DT, 16 gb ram, 128 gb SSD (40 in Use).
3 Days ago I upgraded LO from V7.4.5 to 7.5.0.3
I don’t use functions at all and only notice how slow it is when copy/past, scrolling up and down a 200 row spreadsheet etc! I’m thinking I back go back to the old version next week! I wonder if the additional 19,000 columns may have some to do with it! I only use about 10 columns total! Hope that helps - DN
Lupp, I have attached the SS I’m really having the slow problem with!
2023 All My Stocks.ods (169.9 KB)
Hope this works! Tks DN
Using your attachment I made some experiments with all the operations you listed as “very slow”. Everything worked fast as expected (about instantaneous).
This was with V 7.5.0.3. which I use since it was available. There must be an issue with your user profile or your system settings. You should make a backup of your user profile and run your sheet under a new one for further tests.
In addition: The only problem with the increased number of columns I found was an issue with downward compatibiliy of CF: tdf#152968.
Did you ever try?
You can’t actually delete any column (the object). You can clear it, you can hide it. That doesn’t delete it.
However, the question actually does make sense:
Because it is possible to perform the deletion (e.g., select the respective cells and right-click the selected column headers, then use the respective context menu); and despite the result will not be less overall columns, it may still be something useful: say, removal of some formatting in the cells there, which potentially could affect the performance. And yes, it is possible that the cells there could have something in 7.5, even though those cells simply didn’t exist in the generating application - e.g., because of some imaginary copying of the last defined column (#1024) properties to the extra added columns (I didn’t check the code, but it could be implemented that way).
So overall, the test does make sense. This doesn’t mean it will definitely succeed, and it could even suffer the same problem (creating the new columns with something inherited from the column kept to the left), but still.
2 Likes
so, not as daft as it seems… thanks.
I want to thank everyone for all the advice I have received!! I went to the SS I’m having trouble with, Went to the last column with data in it, deleted about 30 blank columns to the right of the last data column and now everything works and very snappy on all actions. I just deleted 30 columns because I couldn’t figure out how to get to the very last right hand side
column of a 19,000 column SS easily!
Thanks you again for all your efforts!! DN 
1 Like
Congratulations!
But there may come others with a similar looking problem having probably different - or the same- causes.
It would be great to know the actual cause of the issue. It might be useful to look directly into the problematic file without opening it with LibO.
Did you save a backup of the unchanged file for research purposes?
BTW: In cases of the kind it’s essentiai for helpers to know that the problem only afflicts one document.
just goes to prove that sometimes, unconventional solutions can work 