Paul McMillan <p...@mcmillan.ws> added the comment: > Christian Heimes added the comment: > Ouch, the startup impact is large! Have we reached a point where "one size > fits all" doesn't work any longer? It's getting harder to have just one > executable for 500ms scripts and server processes that last for weeks.
This concerns me too, and is one reason I think the collision counting code might be the winning solution. Randomness is hard to do correctly and is expensive. If we can avoid it, we should try very hard to do so... > Christian Heimes said to Marc-Andre: > Have you profiled your suggestion? I'm interested in the speed implications. > My gut feeling is that your idea could be slower, since you have added more > instructions to a tight loop, that is execute on every lookup, insert, update > and deletion of a dict key. The hash modification could have a smaller > impact, since the hash is cached. I'm merely speculating here until we have > some numbers to compare. Interesting point, though I think we might be able to work it out so that we're only adding instructions when there's actually a detected collision. I'll be interested to see what the benchmarks (and real world) have to say about the impacts of randomization as compared to the existing black-magic optimization of the hash function. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13703> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
