Otto Moerbeek wrote [2012-02-14 09:57+0100]:
> New diff, with cast.
>
> Now that the tree isn't locked anymore, I'd like to get this in.
>
> OK?
>
> I'm thinking about parameterizing the hash function so on each run it
> differs a little. Theroretically it could protect against malicious
> code filling the hash with colliding strings and causing a DOS (think
> cgi and related stuff).
>
> -Otto
Since you have sent this to me i am currently looking at table.c.
Of course our hash stuff is implemented as an array of nodes;
the nodes also carry the precalculated hash ("register size") of
the value contained therein to allow for faster testing.
Also nodes are (optionally) relinked (singly) in their slot if
they are accessed, so that statements like the following are
boosted (though there is even more speedup possible using an
instance of a so-called VIEW type):
if (hm.hasKey(key)) {
xy *val = hm.lookup(key);
When i talked about excessive testing i meant splitting the
TeXbook in words and feeding those in, and such stuff. Right?
:)
I guess it would be an enormous boost in access time to implement
a node-based hash here!
And it may need less memory in addition, since 70% treshold looks
like JAVA too me :-)); like i've said, 400% to 1600% percent is
the default treshold-shift for our types (shifts must be in range
1-8, so less than 200% are impossible).
Should i give it a try and convert this to a node-based hash?
I think a replacement for tprintinfo() would be nice to have,
then, too. It may take a week or what, however, i would have to
figure out why these &&DEFINED tests are necessary and so on and
on ...
Your diff works just fine beside that.
Chris Toreks hash rocks.
--steffen
