ParseExcel slow for XL2000?

RandomWalk has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I don't suppose much is different from August when the node Slow Code appeared, but let me add a smidgeon of new info and throw it out to you once more.

I have a script containing

$template = "file.xls";
$xls = Spreadsheet::ParseExcel::Workbook->Parse("$template");
[download]

Now when file.xls is generated by Gnumeric (XL 95 format) these lines execute in under a second. But when file.xls is generated by Excel2000, the same lines take over 85 seconds to execute. The .xls files are quite small--it's more like something is timing out somewhere...

Unfortunately, there is only XL2K where I need this baby to run.

What might be different about the XL2K format the ParseExcel stumbles over?

Thanks

Comment on ParseExcel slow for XL2000? Download Code

Replies are listed 'Best First'.
Re: ParseExcel slow for XL2000? by jmcnamara (Monsignor) on Mar 25, 2004 at 00:31 UTC
What might be different about the XL2K format the ParseExcel stumbles over? Excel 2000 has a option to store more than one Excel version in a file. You can see this in the "Save As" dialog as, for example, "Microsoft Excel 97-2000 & 5.0/95 Workbook (*.xls)". If the workbook is saved in that format then Spreadsheet::ParseExcel may have to read the same data twice. The other difference between Excel 95 and 2000 that might affect the parse speed is that in Excel 2000 all of the strings are stored in a hash table which may take a while to decode. But these are just guesses. The only way to really find out is to use one of the profiling modules to try locate the bottlenecks. Although if you find a bottleneck in Spreadsheet::ParseExcel you probably won't find it easy to fix. `;-)` -- John.	[reply]
Re: Re: ParseExcel slow for XL2000? by dragonchild (Archbishop) on Mar 25, 2004 at 04:01 UTC
Although if you find a bottleneck in Spreadsheet::ParseExcel you probably won't find it easy to fix. ;-) No kidding! I once had to slog through that code to find the source of a crashboom bug and it took me a day just to grok the execution path. Granted, once I grokked it, I was amazed at its simplicty, but I just don't like Hungarian notation. blech ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose	[reply]