Function Specialization

[jbo5112]

I'm working on a program that uses hash maps and a slightly modified
version of the murmurhash2 hash function (I removed the seed). I am
trying to figure out if there is a decent way to write specialized
versions of the hash function for different lengths of strings. If it
helps, I'll be wrapping my hash function inside of an object that just
has a function "int operator() ( const std::string &str ) {return
my_hash(str.c_str(), str.length());}".

The length will be computed at run time, so I don't think I can use
template functions to sort out which one to use. Another program uses
strings with lengths that can be hard coded so I can use class
specialization and special hash functions with different names. Right
now, the only thing I can think of is to have an array of different
functions for any reasonable length (starting from zero length) and a
default that works with any length. I'm thinking a switch statement
or if statements would more than negate any speed gained by the
specialization.

 

[Alan Woodland]

It seems you have a performance/optimization question. The old 'premature
optimization is the root of all evil' rule applies here then. *If* you
have a performance problem, you should perform profiling and find out the
bottleneck; *if* it appears the bottleneck is related to considering
str.length() at run-time, you could construct a relevant compilable demo
program and post it here. Currently it appears you are trying to short-
circuit over several necessary steps.

And yes, if something is not available compile-time, it has to be taken
into account at run-time. This does not automatically mean it would
(measurably) impact the run-time performance.

and to complicate things further you might well find that increasing the
code size of the function, by having 5 versions of it 'optimised' for
different length strings actually hurts you even more than the branches
needed to select (which may/may not be measurable) simply because it no
longer all fits in the cache on your processor.

This sounds awfuly like a lot of work to make less maintainable code
that probably won't be measurably any faster and could even be slower in
the grand scheme of things!

Alan