[Harbour] 2008-11-01 21:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

[Szakáts Viktor]

>>
Hi Mindaugas, Przemek,

>> Thank you. Shouldn't the cast in the changed line
>> be also changed to ( ULONG )?
>
> Yes, It can be changed or removed though it will work without
> warnings as is. BTW it will be more efficient to load whole
> file at the beginning and then decode it but I do not think if it's
> worth to change it. If we change this code to use hb_itemSerialize()/
> hb_itemDeserialize() then it will force such modification. And don't
> worry about the speed. The serialization/deserialization code is  
> really
> fast.

The other issue is that 2 dimensional array. Currently
I'm changing it to 1 dimensional on load, and lookup
is faster this way, and the whole translation array
takes less space. Maybe it doesn't matter, I don't know.

BTW, I've now tested saved size with serialize as is
(2 dimensional), and it's almost exactly the same as
current __i18n_save(). This is pretty good. Then I've
tested loading speed, and it's only the half for
deserialize.

_i18n_loadfrommemory() [1D]: 3.6s
hb_deserialize() [2D]: 6.7s

1000 iterations with strings preloaded from disk,
for 9200 string pairs (682KB file for both) on a P4HT 2.6.

I've repeated the tests by using flattened 1 dimensional
array, which made the serialized files smaller than i18n
functions, and it also made the loading as below:

hb_deserialize() [1D]: 3.95s

Which is pretty good, so the most optimal would be to use
hb_serialize/deserialize with a flat array, flattened
on save. (saving is not speed or memory critical)

I didn't explore hash, as I have zero experience with them.

Brgds,
Viktor