Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Xcl Imp: Performance with large file | ||||||
---|---|---|---|---|---|---|---|
Product: | Calc | Reporter: | bryceman <bryce.schober> | ||||
Component: | ui | Assignee: | AOO issues mailing list <issues> | ||||
Status: | ACCEPTED --- | QA Contact: | |||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues, robin.laing, stp, t8m | ||||
Version: | 638 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows 2000 | ||||||
URL: | ftp://atari-source.com/pub/staroffice/test_data/man123.zip | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
bryceman
2001-10-15 16:15:13 UTC
Hi, we know this problem but we still have Beta state. I think Daniel knows best about the recent development of the Excel import. Regards, Peter I'm currently working on performance enhancements and bug fixes for import/export of huge Excel files and will add your file to my tests. But I think the main problem with this file is that it contains huge charts with >23000 data points. This is a known problem of our chart module and will hopefully be fixed in the planned new chart implementation (see http://graphics.openoffice.org/chart.html). Btw: What are the links at the end of your comments? I cannot see anything there. Reply to Comment 1: The CSV issue is probably more frightening. All that's happening is importing fixed data. Granted, there's a lot of it, but 94 microseconds per cell is horrible. That's an eternity in today's world of computing. Reply to Comment 2: It is most definitely not solely an issue with charting. Please do not miscategorize this issue. I've tried it with and without the charts in the file, and the results were the same. target->OOo2.0 Because of limited resource for OOo2.0, it was decided to shift this tasks to the next milestone. If somebody will be found, who can implement this until OOo2.0, then this tasks will be re-targeted. Just to let you know. I have a spreadsheet with several chart on it, one of them is a simple EUR/USD change tracking chart with about 2300 points. Other data are not huge. When I recalculate spreadsheet it takes about 45 seconds. Removing the chart it calculate istantly. So in my case the problem was the chart.... There should really be a look into this. Here is a blog from a person from zdnet http://blogs.zdnet.com/Ou/?p=102 This shows the test results opening his file. I downloaded his file and confirmed this. Calc can't open the .xml file so I had to save it in .xls and then import it into calc and save it as .ods. I changed 1 column width and then hit save and it took a considerable amount of time to save. Slow loading is a real problem, not just on Windows but also on Linux. It make autosaving even a greater issue. To explain, this is being dicussed on the users mail list and I decided to run my own tests. I created a very large spreadsheet to test with. The file sized are in the 20M (ods). 20M Oct 27 12:13 Large_file_calc_test.ods 52M Oct 27 13:15 Large_file_calc_test.xls Here are timing tests that I did. Problems. Gnumeric doesn't support ODF spreadsheets. KSpread says it will open ODF spreadsheets but crashes on every attempt to open the file. Gnumeric OOo Excel Native Excel.ooo.export Recalc 17.35 1:24.60 >1s 1:09.73 Save 2:21.48 4:32.48 17.65 17.73 Save as 14:35.15 2:40.98 7.64 2:37.22 Open 11.28 2:47.98 10.27 3:58.45 Also this topic came up on /. today. OpenOffice Bloated? http://slashdot.org/article.pl?sid=05/10/27/1425232&tid=185 Note, in Linux. A recent kernel upgrade sped things up to the above timings. It was much slower using the same spreadsheet a few days ago. This at least an improvement. I understand that there is going to be a tradeoff in the converting from ODS to the binary that is necessary to work but there must be a way of speeding this process up. The slashdot article posts two links that go into even further issues of optimization problems. If possible add Linux to the OS or I can create a new issue to cover Linux. I am going to attach a basic version of the spreadsheet I used. This is with most of the rows deleted to minimize the size of the sheet. All that needs to be done to recreate the spreadsheet is to copy row 7 all the way down to row 16501. Sheet 15 is complete as the last cell (F16501) is used for the calculation timing. Created attachment 31171 [details]
Basic test for Large spreadsheet. It needs to have cells copied to work.
My attachment actually requires that all the sheets need to have the cells copied to all the rows down to 16501. I had to modify it further due to the size limit to be uploaded. I find this issue, to which exactly the problem I have in a company that I support. But my surprise is to see that the issue is in 2001, revived in 2005. Now we are in 2010 and OpenOffice.org has its version 3.2. We like. Someday it may solve this? (sorry for my bad English, I'm Spanish speaker, and Google Translator is my friend) |