Score another one for random testing! :)
On Sun, Nov 18, 2012 at 10:26 PM, Danny Yoo d...@hashcollision.org wrote:
On Sun, Nov 18, 2012 at 4:24 PM, Pierpaolo Bernardi olopie...@gmail.com
wrote:
How does compare to builtin mutable hashes?
The following code represents a rough hashtable
I'm doing some micro-optimizations on my rb-tree implementation. One thing
I'm testing is inserting the entire contents of /usr/share/dict/words.
It's heavily dominated by structure-mutation code.
Under 5.3.1, I see the following times:
Timing construction of /usr/share/dict/words:
I don't know if this is the reason, but I do know that Matthew made
the jit able to see thru some structure operations. Perhaps that
enables some other optimizations now that weren't in 5.3.1.
Robby
On Sun, Nov 18, 2012 at 4:50 PM, Danny Yoo d...@hashcollision.org wrote:
I'm doing some
How does compare to builtin mutable hashes?
2012/11/18, Danny Yoo d...@hashcollision.org:
I'm doing some micro-optimizations on my rb-tree implementation. One thing
I'm testing is inserting the entire contents of /usr/share/dict/words.
It's heavily dominated by structure-mutation code.
Yes, a program that is all structure creation, access, and mutation
should run around twice as fast compared to v5.3.1.
At Sun, 18 Nov 2012 17:07:12 -0600, Robby Findler wrote:
I don't know if this is the reason, but I do know that Matthew made
the jit able to see thru some structure
On Sun, Nov 18, 2012 at 4:24 PM, Pierpaolo Bernardi olopie...@gmail.comwrote:
How does compare to builtin mutable hashes?
The following code represents a rough hashtable equivalent of what my rb
code would be enabling (quick search for word by position):
;; We might be curious as to
6 matches
Mail list logo