https://bugs.documentfoundation.org/show_bug.cgi?id=148010
--- Comment #6 from Telesto <[email protected]> --- (In reply to Buovjaga from comment #5) > But what do you have to show proving that ODS format itself makes it > impossible to have performant implementations? Lets start with: I'm don't know any of the specs of the ODS format :-) So don't know what's allowed to do within the file format itself. I'm only having a *vague* recollection of XLSX being faster because of less data.. I think Kohei said so, but well can't find it.. However I can illustrate it: the ODS has a content.xml of 952.596.194 bytes (for the attached file) and the exported XLSX has an Sheet.xml of 406.909.860 bytes (+/-50% the size). Which is an reasonable explanation for the difference in import time. Parsing is smaller xml file faster by definition :-). You can optimize all you want, it always be slower. So XLSX does store less, but apparently this isn't big issue -- The SQLite topic is more some bold idea (of a novice). If you're reconsidering the file format anyhow, you should evaluate the alternatives. The SQLite database has some advantages.. But well this might be wishful thinking an unrealistic.. Third party software probably struggles with such a shift for example. And likely really really complex to implement. ----- The other end of the topic is the current implementation: the "architectural basis of basing it on (mostly) UNO API." Which is mentioned in bug 128204 comment 13 (Noel) bug 108284 comment 15 (Kohei) But well I assume the same UNO API implementation is shared across ODS and XLSX, so this shouldn't make much difference, IMHO. I find the XLSX speed reasonable, but likely someone disagrees -- You are receiving this mail because: You are the assignee for the bug.
