GNOME Bugzilla – Bug 730197
Some ODF files take very long to import
Last modified: 2014-05-20 17:16:16 UTC
Created attachment 276605 [details] Sample file Not only that, gnumeric becomes quite unresponsive after loading. Seems that this concerns files with a database inside. Gnumeric adds autofilters to all columns. With one large file I can't attach loading took around 20 minutes, but after saving as .xls in LO, the xls file tales less than 2 seconds to load. Attached sample does not contain any data, just the headers, but still things are slow.
That file takes a few seconds for me to load. Moving around in the file in any way that causes scrolling takes a long time, though. Here's a typical stack trace.
+ Trace 233607
I don't think this is ods related at all. Saving to xls truncates at 256 columns which is probably why it is faster.
The reporter uses 1.11.x. We had some slow loading issues that have been fixed since then. It's the scrolling we really should be concerned about.
This file when opened has lots of sheet objects. They seem to affect scrolling. The file contains <table:database-range table:name="__Anonymous_Sheet_DB__0" table:target-range-address="Sheet0.A1:Sheet0.AMJ1048576"><table:sort><table:sort-by table:field-number="3" table:data-type="automatic"/></table:sort></table:database-range> We interpret this to mean that we should have auto filters for all those columns...
Our problem is that we seem not to be checking for the table:display-filter-buttons attribute. In ODF 1.2 it defaults to FALSE so we should not be showing those autofilter buttons.
We are now using the table:display-filter-buttons attribute correctly. (Before we were reading it, defaulting to TRUE; but in fact were not using the setting at all.) This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. There is of course still the issue that if one want ed to show the buttons everything would be horribly slow. But that is not an ODF import issue.
The original file still takes around 10 minutes to load. When run in gdb, Ctrl+C always end in gnm_style_unlink_dependent() with traces such as:
+ Trace 233616
And when closing the same file, gnumeric hangs. Typical trace is:
+ Trace 233617
Large areas with conditional formatting?
At least 5 columns have conditional formating (and 1M rows)
Created attachment 276883 [details] A sample file with just the formats It takes some time to load and apparently never closes (or after a very long time).
Give it another go. The fundamental problem is known and hard to fix, but the common case doesn't cause problems.