From: Yusuke Endoh Date: 2015-12-12T16:01:31+09:00 Subject: [ruby-core:72076] Re: [Ruby trunk - Feature #11405] [PATCH] hash.c: minor speedups to int/fixnum keys 2015-12-12 12:21 GMT+09:00 Eric Wong : > But wasn't the goal of adding rehash in r53031 to improve speed and relax the inequality? I don't think so. It just tries to "hide" the inequality from users. It won't improve average speed neither relax the inequality itself, if my understanding is correct. > Perhaps we may rearrange data in contiguous memory for improved locality Interesting. It will not fix the "too long linked list" problem, but reduce cache miss. Or, we may use another hash mechanism suitable for static contents, like perfect hash. 2015-12-12 12:21 GMT+09:00 Eric Wong : > mame@ruby-lang.org wrote: >> Eric Wong wrote: >> > Perhaps teach developers to rehash explicitly. Maybe Hash#freeze >> > can imply rehash, too. But yes, I worry about memory increase more >> > than speed nowadays. >> >> I'm not sure if explicit/implicit rehasing will solve any issue. >> >> The problem is that the linked lists are too(?) long. Long linked >> lists decrease the average access speed, and also makes per-element >> access speed non-uniform. Rehasing will not improve the average >> speed, nor eliminate/relax the inequality. > > But wasn't the goal of adding rehash in r53031 to improve speed and > relax the inequality? > >> It will just make us >> impossible to predict which element is fast to access and which is >> slow. Will this make us happy? > > I mean we may take freeze as a hint from the user to optimize the hash. > > Perhaps we may rearrange data in contiguous memory for improved locality > (like "git repack" or defragmenting a filesystem). I doubt we can have > a compacting GC at this point, but small-scale, explicit compaction > might still work.