Optimize implementations of FromIterator and Extend for Vec #22681

mzabaluev · 2015-02-22T18:58:59Z

Instead of a fast branch with a sized iterator falling back to a potentially poorly optimized iterate-and-push loop, a single efficient loop can serve all cases.

In my benchmark runs, I see some good gains, but also some regressions, possibly due to different inlining choices by the compiler. YMMV.

Use one loop, efficient for both sized and size-ignorant iterators (including iterators lying about their size).

For the first ever element to put into a vector, the branching conditions are more predictable.

Implement both Vec::from_iter and extend in terms of an internal method working with Iterator. Otherwise, the code below ends up using two monomorphizations of extend, differing only in the implementation of IntoIterator: let mut v = Vector::from_iter(iterable1); v.extend(iterable2);

rust-highfive · 2015-02-22T18:59:11Z

r? @gankro

(rust_highfive has picked a reviewer for you, use r? to override)

Gankra · 2015-02-22T19:08:23Z

Can you post your experimental results.

mahkoh · 2015-02-22T19:48:26Z

Does it optimize to a memcpy if the src is contiguous? If not then it will have to be changed anyway.

pczarn · 2015-02-22T21:36:44Z

src/libcollections/vec.rs

+        //          self.push(item);
+        //      }
+        loop {
+            match iterator.next() {


Can you use while let here?

I can, good point.

mzabaluev · 2015-02-22T23:20:28Z

Results of benchmarking on i686: https://gist.github.com/mzabaluev/df41c2f50464416b0a26

tl;dr: Notable losers are (observed consistently over multiple bench runs):

Test	Percentage
bit::bit_vec_bench::bench_bit_vec_big_iter	189%
slice::bench::sort_big_random_small	143%
slice::bench::zero_1kb_from_elem	184%
vec::tests::bench_extend_0000_1000	119%
vec::tests::bench_from_elem_0100	129%
vec::tests::bench_from_iter_0010	121%
vec::tests::bench_from_iter_0100	125%

Winners:

Test	Percentage
string::tests::bench_push_char_two_bytes	95%
string::tests::from_utf8_lossy_100_invalid	38%
vec::tests::bench_extend_0000_0010	87%
vec::tests::bench_extend_0000_0100	89%
vec::tests::bench_from_elem_1000	48%
vec::tests::bench_from_iter_1000	81%

Overall, I don't think too much trust should be put in microbenchmarks repeatedly testing one call-site optimized function.

huonw · 2015-02-22T23:25:38Z

How much is "winning" and "losing'"?

mzabaluev · 2015-02-22T23:26:54Z

@mahkoh These changes should not drastically change the performance with slice iterators, in which case it's as close to reserve + type-aligned memcpy as the optimizer can make it. The main purpose is to provide comparable efficiency for size-unaware or pessimistic iterators.

mzabaluev · 2015-02-22T23:47:46Z

@huonw I've added percentages to the comment above.

pczarn · 2015-02-23T18:56:30Z

Two of these methods have #[inline], but extend_desugared does not; are benchmarks affected? ~~Is there some benefit to having extend_desugared vs calling vector.extend(iterator)?~~ Does extend_desugared change inlining choices, too?

mzabaluev · 2015-02-23T21:51:47Z

I actually ran benchmarks once with #[inline] on extend_desugared, but the results did not look more different than some jitter. I don't think #[inline] has any effect on generic methods, as they are always available in metadata, so the compiler can always choose to inline them across crates. Even less so for unit tests.

mzabaluev · 2015-02-23T21:52:51Z

There should be more benchmarks with extending from sizeless/pessimistic iterators. Any good candidates in libcollections?

Gankra · 2015-02-23T21:57:15Z

BTreeMap's range iter, VecMap's iter, and bitvset's iter have no idea how many elements they contain, but they're all also doing a non-trivial amount of work to actually yield those elements.

mzabaluev · 2015-02-23T22:54:06Z

@pczarn Without looking too closely into the results (I get easily frustrated with the long build times of the library crates and their tests), I assume the optimizer has more "reason" to share extend_desugared if it is used in various places, unless the tradeoff between cache/branch predictor efficiency and removing the overhead of calling leans towards the latter.

steveklabnik · 2015-04-21T13:17:48Z

How do we all feel about this PR today?

Gankra · 2015-04-22T06:40:56Z

Oh geez, this slipped right through the cracks! I don't have a great gut on this since it seems to just be shuffling perf around. r? @huonw

huonw · 2015-04-22T06:49:01Z

src/libcollections/vec.rs

-        if vector.len() == vector.capacity() {
-            for element in iterator {
-                vector.push(element);
+        let mut vector = match iterator.next() {


Hm, does this actually improve performance, over the simpler:

let mut vector = Vec::with_capacity(iterator.size_hint().0); vector.extend_desugared(iterator); vector

This avoids a branch that is present in extend_desugared. That branch tends to be not taken, but in the first iteration the vector is always expanded.

Hm, why it does it avoid that branch? It seems that if the iterator has a non-zero size hint the with_capacity will ensure that it isn't taken, and in the case that the iterator has a zero-size hint it seems both with and without this are equally bad off?

Basically, I'm asking if this was noticeable in practice.

You are right, and it was somehow lost on me that Vec::with_capacity(1) allocates exactly one element. I should simplify the code to your suggestion; the performance difference will likely be negligible.

With the suggested change, vec::bench_from_iter_0000 regresses
from 29 ns/iter (+/- 2) to 87 ns/iter (+/- 48) in my testing
(rebased against commit 3dbfa74), the other benchmarks seemingly unaffected. I wonder if it can be considered an edge case.

Gankra · 2015-05-19T23:13:27Z

@huonw @mzabaluev What's up with this?

Gankra · 2015-05-28T20:49:16Z

Closing due to inactivity.

mzabaluev · 2015-05-29T06:44:25Z

@gankro Ah sorry, I let your request slip by. I believe the branch is good as it is. @huonw's suggestion, while good from code clarity point of view, resulted in some performance degradation as mentioned in the discussion above.

Gankra · 2015-05-30T19:44:24Z

@huonw Any reason not to merge this?

Gankra · 2015-06-04T00:18:28Z

huon's busy

Gankra · 2015-06-09T18:36:37Z

src/libcollections/vec.rs

+        while let Some(element) = iterator.next() {
+            let len = self.len();
+            if len == self.capacity() {
+                let (lower, _) = iterator.size_hint();


Calling size_hint in a loop seems really bad. This is not necessarily a straight-forward or cheap method. Is hoisting it out not worth it in your testing?

It is called exponentially rarely, so it seems fine?

Oh derp, sure.

Gankra · 2015-06-16T23:09:21Z

At worst I like this better than the old code. r+

huonw · 2015-06-16T23:09:55Z

@bors r+

bors · 2015-06-16T23:09:56Z

📌 Commit 7b464d3 has been approved by huonw

bors · 2015-06-17T00:44:26Z

⌛ Testing commit 7b464d3 with merge 0250ff9...

Instead of a fast branch with a sized iterator falling back to a potentially poorly optimized iterate-and-push loop, a single efficient loop can serve all cases. In my benchmark runs, I see some good gains, but also some regressions, possibly due to different inlining choices by the compiler. YMMV.

bors · 2015-06-17T02:48:25Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

mzabaluev added 3 commits February 22, 2015 20:42

Optimize Vec::from_iter and extend

a118b93

Use one loop, efficient for both sized and size-ignorant iterators (including iterators lying about their size).

In Vec::from_iter, unroll the first iteration

032804b

For the first ever element to put into a vector, the branching conditions are more predictable.

rust-highfive assigned Gankra Feb 22, 2015

pczarn reviewed Feb 22, 2015
View reviewed changes

Use while let

7b464d3

mzabaluev mentioned this pull request Feb 26, 2015

RFC: improve CString construction methods rust-lang/rfcs#912

Closed

rust-highfive assigned huonw and unassigned Gankra Apr 22, 2015

huonw reviewed Apr 22, 2015
View reviewed changes

alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 26, 2015

Gankra closed this May 28, 2015

Gankra reopened this Jun 4, 2015

Gankra reviewed Jun 9, 2015
View reviewed changes

bors merged commit 7b464d3 into rust-lang:master Jun 17, 2015

brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Jun 23, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Optimize implementations of FromIterator and Extend for Vec #22681

Optimize implementations of FromIterator and Extend for Vec #22681

mzabaluev commented Feb 22, 2015

rust-highfive commented Feb 22, 2015

Gankra commented Feb 22, 2015

mahkoh commented Feb 22, 2015

pczarn Feb 22, 2015

mzabaluev Feb 22, 2015

mzabaluev commented Feb 22, 2015

huonw commented Feb 22, 2015

mzabaluev commented Feb 22, 2015

mzabaluev commented Feb 22, 2015

pczarn commented Feb 23, 2015

mzabaluev commented Feb 23, 2015

mzabaluev commented Feb 23, 2015

Gankra commented Feb 23, 2015

mzabaluev commented Feb 23, 2015

steveklabnik commented Apr 21, 2015

Gankra commented Apr 22, 2015

huonw Apr 22, 2015

mzabaluev Apr 22, 2015

huonw Apr 22, 2015

mzabaluev Apr 22, 2015

mzabaluev Apr 23, 2015

Gankra commented May 19, 2015

Gankra commented May 28, 2015

mzabaluev commented May 29, 2015

Gankra commented May 30, 2015

Gankra commented Jun 4, 2015

Gankra Jun 9, 2015

huonw Jun 16, 2015

Gankra Jun 16, 2015

Gankra commented Jun 16, 2015

huonw commented Jun 16, 2015

bors commented Jun 16, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015

Optimize implementations of FromIterator and Extend for Vec #22681

Optimize implementations of FromIterator and Extend for Vec #22681

Conversation

mzabaluev commented Feb 22, 2015

rust-highfive commented Feb 22, 2015

Gankra commented Feb 22, 2015

mahkoh commented Feb 22, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mzabaluev commented Feb 22, 2015

huonw commented Feb 22, 2015

mzabaluev commented Feb 22, 2015

mzabaluev commented Feb 22, 2015

pczarn commented Feb 23, 2015

mzabaluev commented Feb 23, 2015

mzabaluev commented Feb 23, 2015

Gankra commented Feb 23, 2015

mzabaluev commented Feb 23, 2015

steveklabnik commented Apr 21, 2015

Gankra commented Apr 22, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gankra commented May 19, 2015

Gankra commented May 28, 2015

mzabaluev commented May 29, 2015

Gankra commented May 30, 2015

Gankra commented Jun 4, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gankra commented Jun 16, 2015

huonw commented Jun 16, 2015

bors commented Jun 16, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015