After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 634803 - slow in reading .xlsx large files
slow in reading .xlsx large files
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
unspecified
Other Windows
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2010-11-14 07:05 UTC by smartxpark
Modified: 2011-08-18 08:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description smartxpark 2010-11-14 07:05:56 UTC 
.xlsx files - are read in but for large files take a lot of time - and crash too

suggested - 

1) activity meter for all operations and calculations
2) <esc> to quit operations - 

reason : I set auto filter and want records 100, 000 records filtered on criteria. 

a) gnumeric is working but doesn't say it is - any keyboard activity and false message - "stopped responding" appears. 

b) Task manager reports Application not working but Processes show Gnumeric chugging away.
Comment 1 Jeremy Bicha 2011-08-12 08:13:38 UTC 
This is obviously not a pessulus bug as pessulus has nothing to do with spreadsheets. I think this was supposed to be a Gnumeric bug.
Comment 2 Geert Janssens 2011-08-12 09:22:58 UTC 
...and you did mean gnumeric, not gnucash ;)

Changing product once more.
Comment 3 Morten Welinder 2011-08-12 12:50:59 UTC 
Clearly Gnumeric -- that's us.

It would be helpful to have a sample file exhibiting this.
Comment 4 Andreas J. Guelzow 2011-08-16 06:14:09 UTC 
Importance Major means: 	Major loss of functionality - menu item broken, data output extremely incorrect, or otherwise difficult/useless to use. 

This does not seem to apply here.

Since 2010-11-14 there have been many changes to the xlsx importer, including xlsx import/export crashes. So without a file showing a different bug (ie. a crash in a recent version of Gnuemric) it is reasonable to assume that that problem is already fixed.

We already have an activity meter for lengthy operations. IT really doesn't make sense to have such a meter for all activities since that would result in a slowdown of those operations. There is a point of having it for specific ops that take a very long time (and that cannot be reasonably sped up). Please file individual bug reports for such operations.
Comment 5 Andreas J. Guelzow 2011-08-18 08:49:39 UTC 
I have added progress feedback to the xlsx import.

Even using 100000 records autofilter condition changes only take 2 to 3 seconds for me. So I don't think progress reporting in that case is necessary. Please file a separate bug report with an attached sample file should you think progress reporting is necessary in that case.

I consider this bug report now closed until furter information may become available.