summaryrefslogtreecommitdiff
path: root/test/benchmarks/lib
diff options
context:
space:
mode:
authorPaul Phillips <paulp@improving.org>2011-08-01 22:44:52 +0000
committerPaul Phillips <paulp@improving.org>2011-08-01 22:44:52 +0000
commit257b6c91a52dc805dfb413b323a70e52f6499c2e (patch)
tree3beafcf862fd0a544338ca0f166ade244cc670a4 /test/benchmarks/lib
parentdaa26379ceae60b441f49dab49f367ebea027529 (diff)
downloadscala-257b6c91a52dc805dfb413b323a70e52f6499c2e.tar.gz
scala-257b6c91a52dc805dfb413b323a70e52f6499c2e.tar.bz2
scala-257b6c91a52dc805dfb413b323a70e52f6499c2e.zip
Sped up traversal over mutable maps by a factor...
Sped up traversal over mutable maps by a factor of two. There was this comment in HashTable explaining why foreach was implemented in terms of iterator. /* * We should implement this as a primitive operation over the * underlying array, but it can cause a behaviour change in edge cases * where: * - Someone modifies a map during iteration * - The insertion point is close to the iteration point. */ Item 1: foreach and iterator didn't behave the same if the map was mutated in the midst of the traversal anyway. Item 2: protecting some particular undefinition of inherently undefined behavior is a pretty unconvincing reason to impose a 2x penalty on foreach. Here are the before/after times for traversing the keys with foreach vs. with iterator. Same impact on values and on the map itself. The benchmark code is included in this commit. before: foreach 143700900 iterator 143848900 after: foreach 67024400 iterator 144890300 Respecting the fact that this might be causing some behavior somewhere to change, even though it would be pretty sick to be relying upon it, ** ATTENTION! POSSIBLE BEHAVIOR CHANGE! ** Review by dragos.
Diffstat (limited to 'test/benchmarks/lib')
0 files changed, 0 insertions, 0 deletions