Question

I have an application which makes maximum usage of recursive functions . Basically its a string parser which uses a hash map as its data structure . We are facing an issue wherein for complex and long strings the performance is severly hit . We have dared not touch the hash function , in the fear of regression. What has been observed is a massive recursive function calls which we suspect is causing the performance issue . The application is a C++(Windows) based developed in VS 2008

Will increase in stack reserve size and stack commit size improve application performance ? OR
Will it avoid Out of Memory issues which we come across , but not frequently

Answer 1

Stack usage in itself will not significantly affect performance. It’s possible that the cost of making function calls (which happen to be recursive calls) is a significant part of the runtime of your hash function, and if so it’s possible that an iterative version would be faster.

Maximal usage of recursion in C++ is potentially inefficient and is also somewhat dangerous, since stack size is limited. For example,

size_t hash(const std::string &s) {
    if (s.size() == 0) return 0;
    return s[0] + 31 * hash(s.substr(1));
}

This is probably inefficient for two reasons (the call overhead and the likelihood that it allocates loads of strings), and also will crash with a stackoverflow when passed a long enough string.

We have dared not touch the hash function , in the fear of regression

Even aside from performance, the hash function used in a hash map should be isolated for ease of maintenance — one copy of the code, and no assumptions anywhere else that any particular hash algorithm is used.

If you can isolate the hash function, then you can dare to touch it. That way you can easily compare different hash algorithms and different implementations (including recursive / non-recursive) to see whether they solve your overall performance issue.

If you can’t isolate the hash function, then you’ve learned a lesson about code design. You might still be able to replace it, though, and get an idea of whether it affects performance without knowing for sure that the code is still correct. If you can make it faster then it’s worth trying to make it correct (by modifying the rest of your code to isolate the hash function and then replacing it). If the best hash function you can come up with isn’t faster then it doesn’t really matter whether it’s correct or not, since there’s no grounds to use it.