Rust

7274 readers

3 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

kahnclusions@programming.dev

torcherist@programming.dev

"Clean" Code, Horrible Performance in Rust (chrs.dev)

submitted 1 year ago by chrs@programming.dev to c/rust@programming.dev

25 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] Turun@feddit.de 7 points 1 year ago (12 children)

It would be interesting to see if an iterator instead of a manual for loop would increase the performance of the base case.

My guess is not, because the compiler should know they are equivalent, but would be interesting to check anyway.

[–] onlinepersona@programming.dev 1 points 1 year ago* (last edited 1 year ago) (9 children)

Do you mean this for loop?

for shape in &shapes {
  accum += shape.area();
}

That does use an iterator

for-in-loops, or to be more precise, iterator loops, are a simple syntactic sugar over a common practice within Rust, which is to loop over anything that implements IntoIterator until the iterator returned by .into_iter() returns None (or the loop body uses break).

Anti Commercial AI thingy

CC BY-NC-SA 4.0

[–] arendjr@programming.dev 9 points 1 year ago (8 children)

I think they meant using for accumulating, like this:

shapes.iter().map(Shape::area).sum()

[–] Turun@feddit.de 4 points 1 year ago

Yes. That's what I meant.

Though I heavily expect the rust compiler to produce identical assembly for both types of iteration.

load more comments (7 replies)

load more comments (9 replies)