diff options
author | Paul Phillips <paulp@improving.org> | 2011-08-01 22:44:52 +0000 |
---|---|---|
committer | Paul Phillips <paulp@improving.org> | 2011-08-01 22:44:52 +0000 |
commit | 257b6c91a52dc805dfb413b323a70e52f6499c2e (patch) | |
tree | 3beafcf862fd0a544338ca0f166ade244cc670a4 /test/benchmarks/lib | |
parent | daa26379ceae60b441f49dab49f367ebea027529 (diff) | |
download | scala-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