Bug 87082

Summary: automatic-styles style-name attribute could be shorter
Product: LibreOffice Reporter: Jérôme <jerome.bouat>
Component: filters and storageAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WONTFIX    
Severity: normal CC: dtardon, jerome.bouat, jmadero.dev, robinson.libreoffice
Priority: medium    
Version: 4.1.6.2 release   
Hardware: Other   
OS: All   
Whiteboard:
Crash report or crash signature: Regression By:

Description Jérôme 2014-12-07 22:18:44 UTC 
In a spreadsheet document, the "content.xml" file contains :
-----
<style:style style:name="ce165" style:family="table-cell" style:parent-style-name="Default">(...)</style:style>
(...)
<table:table-cell table:style-name="ce165" table:number-columns-repeated="3"/>
-----

The "ce165" value could be shorter.

It seems that the 2 first letters represent the type (cells in this example). However, this type could be defined with only 1 letter (let's say "e" for this example).

Next the number "165" seems to represent an identifier within all cells types. Again, this identifier could be shortened by using a higher base number representation. For exemple "165" with decimal representation becomes "A5" with hexadecimal representation or less in most cases with base 64 representation.

Finally, this style name example could become "eA5" with hexadecimal representation.

I understand that the file compression hides a part of this issue on the final libreoffice file size. However this possibly slower the read or the write of the uncompressed "content.xml" file.
Comment 1 Joel Madero 2014-12-12 06:29:49 UTC 
We need developer input on this as I'm not sure if there is a rationale for it being the way it is (or if there is a real chance of it ever changing).
Comment 2 David Tardon 2015-01-15 15:33:38 UTC 
Do you have numbers showing your idea would cause any measurable speed-up? Because I doubt it very much.
Comment 3 Michael Meeks 2015-01-15 15:38:47 UTC 
I guess - I'd want to see a profile here; also the FastParser does the parsing in a separate thread, so from a parsing & memory allocate / free perspective - this is nearly ~free - as soon as we have the ODF filter(s) converted to the FastParser.
Comment 4 Robinson Tryon (qubit) 2015-01-15 19:43:05 UTC 
(In reply to David Tardon from comment #2)
> Do you have numbers showing your idea would cause any measurable speed-up?
> Because I doubt it very much.

(Jerome: once you have some feedback to share, feel free to change status back to 'UNCONFIRMED'. Thanks)
Comment 5 Jérôme 2015-01-17 13:21:38 UTC 
Sorry, I have currently no time available for providing accurate statistics.

However, I can list the below benefits :
- less energy consumption (important for laptops)
- possibly a faster parsing
- possibly a faster compression/uncompression
Comment 6 Joel Madero 2015-01-17 22:01:44 UTC 
I am closing this as WONTFIX. If OP ever has the time/desire to actually give numbers vs "possible benefits" then please provide those numbers and you can set this one back to UNCONFIRMED. Thanks
Comment 7 Robinson Tryon (qubit) 2015-12-18 10:24:10 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2016-09-19 16:47:56 UTC Comment hidden (obsolete)