Bug 462066 - OO-Calc extremely slow with large spreadsheets
OO-Calc extremely slow with large spreadsheets
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
10
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Tardon
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-12 08:13 EDT by Paul F. Johnson
Modified: 2009-03-18 11:01 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-18 11:01:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CSV file for testing (18.13 KB, application/octet-stream)
2008-09-12 08:13 EDT, Paul F. Johnson
no flags Details

  None (edit)
Description Paul F. Johnson 2008-09-12 08:13:33 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):
3.0.0-5.1

How reproducible:
Always

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)
  
Actual results:
Refresh slows down at 100 and crawls by 200

Expected results:
Negligable slow down

Additional info:
I have all of the OpenGL stuff switched off, dither off and refresh object off.
Graphics card driver, xorg-x11-nv-drv
Comment 1 Caolan McNamara 2008-09-12 08:45:40 EDT
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.
Comment 2 Paul F. Johnson 2008-09-12 08:57:04 EDT
I'll give it a shot with the nouveau driver and see what gives. OOo-writer is running fine.
Comment 3 Paul F. Johnson 2008-09-12 08:57:38 EDT
You also have to fill the column in - odd numbers here and there don't seem to give it a head ache...
Comment 4 Caolan McNamara 2008-09-12 09:07:02 EDT
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
Comment 5 Paul F. Johnson 2008-09-12 09:27:41 EDT
you have to type it - sorry :-(

Changing the driver made no difference either. Looks like my card is not supported by nouveau.
Comment 6 Paul F. Johnson 2008-09-12 09:28:37 EDT
You can miss some (but not many) rows.... Just press 1, arrow down etc etc
Comment 7 Caolan McNamara 2008-09-16 11:57:02 EDT
As a thought, can I get the output of /usr/lib/openoffice.org3/crash_report -stack /dev/null
to rule a11y in or out
Comment 8 David Tardon 2008-09-17 13:47:46 EDT
I've reproduced it on my laptop (i386).
Comment 9 Caolan McNamara 2008-09-17 14:16:42 EDT
And is accessibility enabled or not ?
Comment 10 David Tardon 2008-09-18 02:49:32 EDT
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?
Comment 11 Paul F. Johnson 2008-09-18 05:03:10 EDT
Yep - they're the settings I have
Comment 12 Caolan McNamara 2008-09-18 06:04:57 EDT
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.
Comment 13 David Tardon 2008-09-18 08:04:33 EDT
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".
Comment 14 Caolan McNamara 2008-09-18 08:33:28 EDT
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.
Comment 15 David Tardon 2008-09-18 08:55:22 EDT
dtardon->caolanm: No "Check in all languages" is off now. Only these options which I listed are on.

All my hunspell packages:

hunspell-1.2.1-7.fc9.x86_64
hunspell-devel-1.2.1-7.fc9.x86_64
hunspell-en-0.20080207-1.fc9.noarch
Comment 16 Caolan McNamara 2008-10-07 04:41:26 EDT
caolanm->dtardon: Can you take over this one and try and sort it out.
Comment 17 David Tardon 2008-10-07 04:51:48 EDT
dtardon->caolanm: I've been actually working on it, only forgot to update Assignee and Status fields (again).
Comment 18 Bug Zapper 2008-11-25 22:03:33 EST
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Caolan McNamara 2009-03-18 08:40:52 EDT
Do you still think this is "check all languages" because if so, then I believe that in 3.1 that feature has gone away.
Comment 20 David Tardon 2009-03-18 10:29:19 EDT
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.
Comment 21 Caolan McNamara 2009-03-18 11:01:03 EDT
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)

Note You need to log in before you can comment on or make changes to this bug.