Red Hat Bugzilla – Bug 462066
OO-Calc extremely slow with large spreadsheets
Last modified: 2009-03-18 11:01:03 EDT
Created attachment 316563 [details]
CSV file for testing
Description of problem:
I have imported a CSV file in and set the type to ISO-8859-15(Euro), inserted a new column. After about 100 rows, the refresh starts slowing down. After about 200 rows, it is extremely slow.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Import the CSV file attached to this BZ and set as ISO-8859-15
2. Insert a new column between the existing B and C
3. Start typing in the new column (random numbers)
Refresh slows down at 100 and crawls by 200
Negligable slow down
I have all of the OpenGL stuff switched off, dither off and refresh object off.
Graphics card driver, xorg-x11-nv-drv
I don't see this on my x86_64, by inserting the new column and typing some numbers in the new column, scrolling down a bit with the scroll wheel and typing in some more.
But I'm using nouveau driver at the moment, I'll try with nv later. Though I seem to recall some upstream bugs like this, that come and go without resolution or reason.
I'll give it a shot with the nouveau driver and see what gives. OOo-writer is running fine.
You also have to fill the column in - odd numbers here and there don't seem to give it a head ache...
Well, I now tried typing in one number of 111, copying the content, and selecting 500 rows and pasting the content over all, and that looked ok.
I hope there's some route to reproducing it that doesn't involve typing in hundreds of rows of numbers manually
you have to type it - sorry :-(
Changing the driver made no difference either. Looks like my card is not supported by nouveau.
You can miss some (but not many) rows.... Just press 1, arrow down etc etc
As a thought, can I get the output of /usr/lib/openoffice.org3/crash_report -stack /dev/null
to rule a11y in or out
I've reproduced it on my laptop (i386).
And is accessibility enabled or not ?
Looks like a11y is innocent this time. After checking the configuration, I'm able to reproduce it even on my workstation (x86_64). The slowdown shows up after I've enabled--in Language Settings/Writing Aids/Options--"Check spelling as you type", "Check in all languages" and "Do not mark errors".
-> paul: can you confirm you have all these options enabled?
Yep - they're the settings I have
I'm screwed if I can see this. I can see something suspicious with a11y enabled, but I want to be sure we're tackling the right problem.
caolanm->dtardon: Want a go at this, as you seem to have a better grip on how to make it happen. Punishment for being able to see it I guess :-)
As a wild stab, perhaps if "check in all languages" is a factor in the slowdown then it might be a factor of the number of dictionaries, or some particular hunspell dictionary installed.
I've pruned it a little more and got only the following items enabled in Language Settings/Writing Aids: "Available Language Modules/Hunspell SpellChecker", "ALM/Libhyphen Hyphenator", "User-defined dictionaries/IgnoreAllList", "Options/Check spelling as you type". That is something like a bare minimum for the slowdown to exhibit (I haven't been able to uncheck the "Libhyphen Hyphenator"--when I do it, it will show checked on next opening of Options dialog). It certainly ceases to exist after I uncheck "Options/Check spelling as you type".
The common theme now revolves around spell-checking, but I'm a little confused...
caolanm->dtardon: is "Check in all languages" on or off now to reproduce this, i.e. is that a factor at all. Because I continue to see no particular slowdown after inserting a column and typing 100 to 200 lines of random numbers into it after pressing "down" after each one.
But I have only hunspell-en installed, so if it needs to be "on" to see this problem then the output of rpm -qa | grep hunspell would be likely relevant.
dtardon->caolanm: No "Check in all languages" is off now. Only these options which I listed are on.
All my hunspell packages:
caolanm->dtardon: Can you take over this one and try and sort it out.
dtardon->caolanm: I've been actually working on it, only forgot to update Assignee and Status fields (again).
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
Do you still think this is "check all languages" because if so, then I believe that in 3.1 that feature has gone away.
dtardon->caolanm: Seems it's not reproducible anymore--neither in 3.0.1 nor in 3.1 . From some notes I digged out I tried (and reproduced) it just before Christmas (it was still 3.0 in F-10 then, right?). I'm not sure if I have ever tried it after that.
Maybe we got lucky and upstream found the problem and fixed it in 3.0.1 and we benefited from that. We don't have a reproducible problem anymore apparently anyway there, and if it *was* check all languages then that's gone away in 3.1
(Though if that's a good thing or not I dunno, though if one ends up with 139 hunspell dictionaries installed I guess it could be seen as a good thing)