diff options
| author | Rex Kerr <ichoran@gmail.com> | 2014-02-10 02:17:27 -0800 |
|---|---|---|
| committer | Rex Kerr <ichoran@gmail.com> | 2014-02-25 05:39:13 -0800 |
| commit | c5962b1871f8093fe200fe0c47cd9c202b07a8f9 (patch) | |
| tree | 8ca06a81c39c11c44f10dabd23499b63506dbda7 /test/files/pos/list-optim-check.flags | |
| parent | 1ea43ffb2286d63e133839c1ea0b09449b0ac168 (diff) | |
| download | scala-c5962b1871f8093fe200fe0c47cd9c202b07a8f9.tar.gz scala-c5962b1871f8093fe200fe0c47cd9c202b07a8f9.tar.bz2 scala-c5962b1871f8093fe200fe0c47cd9c202b07a8f9.zip | |
SI-8240 Consider rolling back optimizations for List
Some compiler-specific optimizations turn out to be very helpful for Lists in general.
* List map can be a lot faster (up to 5x!)
* List collect can be considerably faster (up to 3x)
* List flatMap can be a bit faster (2x)
* List take can be slightly faster (1.1x) and have better structural sharing
These appear to be unqualified wins (tested), even in a scenario with mixed collections. This is expected: detecting the builder is faster than the otherwise mandatory object creation, and multiple dispatch is mostly a wash since it was already multiple dispatch in getting to the builder.
With -optimize, map is not always such a big win, but is never slower.
Also added @noinline to map to work around an optimizer bug (SI-8334) and added a test to check that the pattern that triggers the optimizer bug does not affect any of the map-like methods.
Diffstat (limited to 'test/files/pos/list-optim-check.flags')
| -rw-r--r-- | test/files/pos/list-optim-check.flags | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/test/files/pos/list-optim-check.flags b/test/files/pos/list-optim-check.flags new file mode 100644 index 0000000000..49d036a887 --- /dev/null +++ b/test/files/pos/list-optim-check.flags @@ -0,0 +1 @@ +-optimize |