[unwind]

Whoa. That file contained the absolutely most naive string hash function I've ever seen:

    static int get_string_hash(const char *s)
    {
	int val = 0;

	if (s == NULL)
	    return val;

        while (*s)
	    val += *s++;

        return val & ALISP_OBJ_PAIR_HASH_MASK;
    }

It seems to cleverly avoid everything that's supposed to go into a string hash function, and makes me quite wary of the rest of the file's code quality. I stopped reading after checking that this function is indeed used (it is).

Also, the file itself was last modified on 2011-10-18, which seems to be pretty recent for something that's not used. Perhaps they're gearing up to start using it, and if that's going to involve any kind of even remotely performance-sensitive, I hope they replace the hash function first. :)

[albertzeyer]

I'm curios, what is (under normal circumstances) supposed to go into a string hash function?

The biggest problem I see with this hash function is that it will produce very many collisions (because most common strings will probably produce only small numbers).

I have seen other very simple string hash functions which just take the 4 first bytes (or 4 last or some sort of other pattern) of the string and use them (interpreted as 32bit integer) as the hash.

[unwind]

I'm no expert in hash function design, but one thing that seems bad is that it will generate colliding hashes for all permutations of the same characters. Also, it will not "spread" the bits very well, due to just using addition. Most "real" hash functions tend to multiply the hash by each new character, thus causing it to "churn" more.

[arethuza]

That's probably still better than the string hash in really early versions of Java, which only looked at a relatively small number of characters at the start of the string.