I can improve the speed by reading hash items in raw form
but it may cause some bad side effects because hashes uses
national collating by default. IMHO it's wrong and I would
like to change it. The default should be binary collating
we optimized for speed. If user wants then he can enable
national sorting order by hb_hSetBinary( hValue, .F. ) or
hb_hSetCaseMatch( hValue, .F. ). Simple binary sorting
should give noticeable speed improvement. But in such case
I can try to trust that the order read from serialized data
is correct and eliminate hash array resorting.
Hi,
I see Przemek has already implemented national/binary hash ordering, so
my remarks are too late, but I really do not understand a problem here.
From my point of view hash is a way to obtain data value by key value
(not by number like in array). The internal implementation of the hash
it is hash's business.
Have we documented, that hash uses sorted array and binary search to
find a key value? Have we documented that HB_HGETKEYS() should return
string keys in ascending order? If we did it, then it's a documentation
bug!!! I think hash is hash, and user code should not depend on hash
internal implementation.
We can use any algorithm for sorting keys. We can also use the real
hashing algorithm, i.e. generate some checksum of key, and try to find
value using this checksum. In this case national/binary sorting is not
used at all.
So, I do not understand at all, why do we need hb_hSetBinary() and
hb_hBinary()?!It should be hash's internals and users should not care
about it!
Best regards,
Mindaugas
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
