|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | slow adjusting of row height when loading ods spreadsheet | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Calc | Reporter: | cphilipp <christianphilipp> | ||||
| Component: | open-import | Assignee: | AOO issues mailing list <issues> | ||||
| Status: | CONFIRMED --- | QA Contact: | |||||
| Severity: | Trivial | ||||||
| Priority: | P3 | CC: | gbjim.andrews, issues, larusso, maison.godard, mwpowellhtx, ooo.redflag, shitpoet | ||||
| Version: | OOo 2.0.3 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
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. Created attachment 38352 [details]
an example where this problem happens
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. Hi Niklas, as enhancement for the performance of the adapt row height process this one is for you. Frank Still problem for me in OOo 3.1.1 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) 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... Hi, 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. Using: 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. Frustrating.......... Thanks for a great product and your time. Jim *** Issue 126621 has been marked as a duplicate of this issue. *** Reset the assignee to the default "issues@openoffice.apache.org". *** Issue 85034 has been marked as a duplicate of this issue. *** *** Issue 127854 has been marked as a duplicate of this issue. *** |
Hi, 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?) hint: 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.