Daniel Carrera wrote:
I haven't yet seen any examples of the new Excel format. But verbosity
isn't really an issue.
snip <
The number of characters has no effect on speed. There is no reason why
<w:r> is faster to parse than <text:span text:style-name="T1">.
I'm sorry, Daniel, but I find that hard to believe.
I have a file that is strictly text, numbers, and dates. Seven columns
by 63,260 rows -- no formulas, no formatting. Importing as csv takes a
few seconds. Converted to ods it takes *much* longer to load -- around
30 seconds or so.
The original csv is 3.945 MB. The content.xml of this file is 44.305 MB.
A ratio of over 11 to 1. I can't say that it takes eleven times as long
to load -- I haven't timed it that close -- but it's in the ballpark.
Keep in mind that at the end of the day, the program has to end up with
exactly the same data structures and it starts out with basically the
same information.
I just don't understand why it takes over 80 characters to describe a 4
character text value in a cell with no formatting:
<table:table-cell
office:value-type="string"><text:p>arin</text:p></table:table-cell>
You're not going to convince me that couldn't be usefully abbreviated in
some way and that all that doesn't take cycles to process.
I "get it" about ODF, Daniel, I really, really, do. I'm a supporter. But
that doesn't mean we can just pretend that disadvantages don't exist.
The worst part is that the performance hit is something that the user
will experience every day, while the advantages may not be so readily
apparent -- or even applicable at all, depending on how you use the suite.
--
Rod
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
