Add performance tests for Map/Set with String and Object keys

Add performance tests for Map/Set with String and Object keys

The big change here is to split out each key type into its own
benchmark suite, since optimizations for different key types
are likely to be disjoint. ForEach tests have also been split
into separate "Iteration" suites, again with the thought that
iteration performance is likely separable from key type.

As part of adding the new tests, rejiggered the existing tests:
  - Map.set and Set.add (along with their Weak variants) no longer
    include construction costs in their scores
  - Moved key logic into the shared common.js

R=arv@chromium.org, machenbach@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=24969

[adamk, 2014-10-28 16:56:32]

adamk@chromium.org changed reviewers:
+ dslomov@chromium.org, machenbach@chromium.org

[adamk, 2014-10-28 16:56:33]

machenbach, are these new suite names OK? Do you know what will happen to the
old data once the simple "Map" and "Set" names stop getting output by these
tests?

[arv (Not doing code reviews), 2014-10-28 18:02:05]

arv@chromium.org changed reviewers:
+ arv@chromium.org

[arv (Not doing code reviews), 2014-10-28 18:02:06]

Logic LGTM

[Michael Achenbach, 2014-10-29 08:20:54]

Infra LGTM

[Dmitry Lomov (no reviews), 2014-10-29 10:02:25]

https://codereview.chromium.org/685753004/diff/1/test/js-perf-test/Collection...
File test/js-perf-test/Collections/map.js (right):

https://codereview.chromium.org/685753004/diff/1/test/js-perf-test/Collection...
test/js-perf-test/Collections/map.js:7: new Benchmark('Set', false, false, 0,
MapSet, MapSetupSmiBase, MapTearDown),
In this perf test, you reuse MapSet/MapHas/MapGet/MapDelete between different
types of keys. This means that (in the future highly optimized world) if the
tests are run consequently, each of these functions might  be specialized to a
particular type of a key, and then deopted and re-compiled for a different type
of a key. This means that the test perf results will depend on the order of test
runs, which is not happy.

AFAIU, this is not the case today since we do not really optimize map accesses
well, but something to consider.

[adamk, 2014-10-29 10:17:31]

On 2014/10/29 at 10:02:25, dslomov wrote:
>
https://codereview.chromium.org/685753004/diff/1/test/js-perf-test/Collection...
> File test/js-perf-test/Collections/map.js (right):
> 
>
https://codereview.chromium.org/685753004/diff/1/test/js-perf-test/Collection...
> test/js-perf-test/Collections/map.js:7: new Benchmark('Set', false, false, 0,
MapSet, MapSetupSmiBase, MapTearDown),
> In this perf test, you reuse MapSet/MapHas/MapGet/MapDelete between different
types of keys. This means that (in the future highly optimized world) if the
tests are run consequently, each of these functions might  be specialized to a
particular type of a key, and then deopted and re-compiled for a different type
of a key. This means that the test perf results will depend on the order of test
runs, which is not happy.
> 
> AFAIU, this is not the case today since we do not really optimize map accesses
well, but something to consider.

Given that my next step was to start on optimizing the Smi case, I've decided to
take care of this now (added separate mutation functions for each type of key).

[adamk, 2014-10-29 10:18:49]

Committed patchset #2 (id:20001) manually as 24969 (presubmit successful).

[Dmitry Lomov (no reviews), 2014-10-29 11:09:52]

lgtm