Bug 87082 - automatic-styles style-name attribute could be shorter
Summary: automatic-styles style-name attribute could be shorter
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.1.6.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-07 22:18 UTC by Jérôme
Modified: 2016-09-19 16:47 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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)