On Friday 21 Oct 2011 19:27:25 [email protected] wrote:
> Hmmm I wonder if there isn't a way to get this to a reasonable size. It
> sounds weird that the index into the data is 20 times bigger than the data
> itself.
It's because a lot of the data is duplicated for variants of the same
calendar, e.g. the Thai, Japanese, RoC, ISO8601 and Julian calendars all use
the same Gregorian month and day names, Islamic and IslamicCivil use the same
data, etc. Also many locales default to the English names for calendars they
don't have translations for, like Ethiopic or Indian.
I also optimised the existing data storage, the standalone month and day names
didn't need to be stored separately from the format versions when most of the
time they are the same, so that reduced the difference.
The index into that data however is 368 locales times by 15 calendars times 43
calendar data fields times by 2 quint16's for index and size = 949kB extra
memory required.
I could cut the 949kB back by removing the 7 duplicate calendars for the names
but not the formats, giving a reduction of 368 * 7 * 30 * 2 * 2 = 309kB, so
640kB extra for the index then.
The indices are also stored as quint16 when there are many fields may only
need quint8, especially size, which could save 45B per index = 132kB saving =
508kB index.
Huh, that's less than the 2.75 MB extra I said? Ah I took source file size,
stupid me, I shouldn't write emails so late at night. That could change
things.
Let's try that maths again just on actual bytes.
Qt 4.8
88 index fields * 368 locales = 64kB index
index = 64kB
data = 174kB
total = 238kB
Qt 5.0
133 index fields * 368 locales = 98kB main index
main index = 98kB [excludes calendar index]
data = 180kB
total = 278kB
full cal index = 949kB, so total = 1227kB
trim cal index = 640kB, so total = 918kB
no-fat cal index = 508kB, so total = 786kB
Better, but still not brilliant.
> I think there's a general question we will need to discuss first: Do we
> want to explicitly depend on ICU or not. I guess we'll have some
> discussions around this next week at Dev Days :)
Interesting question :-) Shame I can't be there to discuss it. Unless....
Anyway, there's pro's and con's. It is a 17MB dependency, but it's usually
already installed on Linux, and OSX uses it anyway, so it's only Windows and
embedded that could be an issue.
Would we just be using it to get the data, or for the parsers / formatters /
calculators etc as well? If the latter it would save us a lot of work on new
features, but we might have issues integrating it into our existing api's and
classes, and it could be a lot of work. It would also make most of the code
I've just written redundant :-)
I've also just finished writing another email about QLocale changes which KDE
would like which I'll send on anyway as part of the discussion.
Cheers!
John.
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
