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
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
