Issue 67412 - slow adjusting of row height when loading ods spreadsheet
Summary: slow adjusting of row height when loading ods spreadsheet
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: OOo 2.0.3
Hardware: PC Windows XP
: P3 Trivial with 10 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 85034 126621 127854 (view as issue list)
Depends on:
Reported: 2006-07-15 19:39 UTC by cphilipp
Modified: 2018-08-27 08:59 UTC (History)
7 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

an example where this problem happens (147.98 KB, application/x-compressed)
2006-08-08 22:24 UTC, cphilipp
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description cphilipp 2006-07-15 19:39:48 UTC

I have a huge ods spreadsheet, about 300000 cells in 23 tables, with a lot of
database like operations on it (counting & pattern matching, DBMIN, DBMAX). The
overall size of the document is about 3 MB. 
Naturally loading is slow.
On my Athlon X2 4200+ dual core with 2 MB RAM loading takes about 2:20 min.

The steps done during loading according to the messages shown in the status bar:
Loading:              0:14 min
Calculating:          0:25 min
Adjusting Row height: 1:40 min ("Zeilenhöhe anpassen" in my german version)

I have changed most rows to use standard row height, which improved the loading
time a bit. (Figures above have been taken after this optimization)
As the progress bar for "adjusting row height" was running often, I assume, this
step has been done for each table.

To improve the loading time I would like to make the following proposal on
adjusting the row height:
- check whether this is really necessary to be done during loading, before the
user can work with the spreadsheet.
- It might be necessary for the table selected, as mouse events must be handled
by the correct cell, so if the user can click to a cell, it should be after the
rendering of cells.
- For all other tables this step can either be done in the background or when
the user changes to a table not rendered yet. (rendering the cells is pure
layout, it will not have influence on cell content, right?)

The spreadsheet was converted from StarOffice 5.2 calc format, where the size
was about 40 MB (!, things improve!). If the conversion is part of the problem,
maybe also the import function for this format should be improved.
Comment 1 kpalagin 2006-08-06 15:03:39 UTC
Can you post your .ods? Or at least indicate that you can provide it privately 
to developers?
P.S. Dual-core is not really helpfull because OOo is likely to do all work in 
single thread. All you currently get is better responsiveness in other apps.
Comment 2 cphilipp 2006-08-08 22:24:19 UTC
Created attachment 38352 [details]
an example where this problem happens
Comment 3 cphilipp 2006-08-08 22:33:28 UTC
So, it was  not easy, but I managed to shrink the file to a reasonable size,
change data to dummy data and let the problem still happen.

Still the adjusting of row height takes 3 times longer than loading and
recalculating together. (but now all together less than one min.)

I have changed my mind, I think that the progress indicator might begin from the
left side again, when the right end is reached. This gave me the impression that
the progress indicator was running for each table. But I'm no longer sure about
that, this might happen with no relation to any tables.
But I'm sure that the indication "Adjusting Row height" still is the most time
consuming operation when loading the example attachment.
Comment 4 frank 2006-08-31 11:35:43 UTC
Hi Niklas,

as enhancement for the performance of the adapt row height process this one is
for you.

Comment 5 prozacr 2009-11-08 19:40:05 UTC
Still problem for me in OOo 3.1.1
Comment 6 zzarko 2010-06-03 09:08:30 UTC
I'm using Ubuntu 9.10 with OOo 3.1.1. I've found out that if I set
"Tools/Options/Language Settings/Languages/Locale" setting to "Default", opening
one of my documents with a lot of macros and formulas takes 12 seconds, but if I
set that setting to, for example, "Serbian Latin", opening of the document takes
1 minute and 45 seconds (with almost all that time taken by "Adapt row height").
I guess that somwhere there lies the (part of a) problem... (I've sent this on
sevral bug reports dealing with the similar issues)
Comment 7 eremmel 2011-01-01 13:55:14 UTC
Annoying is that this height recalculation happens on various occasions during
saving, some other editor tasks, so it should be come a bug i.s.o. enhancement.

It makes Calc unusable.

It goes away when I disable 'wrap text automaticly', but that is not handsome
when one has large texts in one column...
Comment 8 La Russo 2012-06-24 11:41:55 UTC

im using Open Office 3.4 (German) and the bug still exists.

I have to use Excel 2010 to work with my documents. - no problems by using Excel.

Open Office still cant handle Documents with more than about 2000 rows because of this bug.
Comment 9 GBJim Andrews 2015-10-11 21:47:26 UTC
Win7; service package 1
Open Office 4.1.1
Copied info info from .csv file to .ODS 27,000 rows.

First time copied great. then changed row height, col size, font & size, etc. 
Saved as .ODS file.

Next couple of times opened great (including adapt row height), but subsequent opening, the file hangs forever on 'adapt row height'. rebooted, flushed recent files but stilkl can't open.

Recreated in new spread sheet from .CVS file and readjusted formatting as above, saved in .ODS file and opens last 10 times just fine.

First file was sent to friends and a few can open OK, but some can't.

Thanks for a great product and your time.
Comment 10 oooforum (fr) 2015-11-02 13:17:29 UTC
*** Issue 126621 has been marked as a duplicate of this issue. ***
Comment 11 Marcus 2017-05-20 10:45:24 UTC
Reset the assignee to the default "".
Comment 12 oooforum (fr) 2018-08-27 08:58:04 UTC
*** Issue 85034 has been marked as a duplicate of this issue. ***
Comment 13 oooforum (fr) 2018-08-27 08:59:02 UTC
*** Issue 127854 has been marked as a duplicate of this issue. ***