Avoid chain() in find_constraint_paths_between_regions().

[nnethercote]

This iterator can be hot, and chained iterators are slow. The second
half of the chain is almost always empty, so this commit specializes the
code to avoid the chained iteration.

This change reduces instruction counts for the wg-grammar benchmark by
up to 1.5%.

[rust-highfive]

r? @estebank

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

[nnethercote]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 60fa535 with merge c30cab8...

[PlasmaPower]

I'd get rid of the is_empty check, and move the code currently in .map( into the for loop. I don't think checking is_empty before the loop will be any faster, even if it is indeed empty, but I'm not an expert on optimization.

Also, you're currently calling self.applied_member_constraints(r) again if it does have elements when you could just reuse the previous call's result.

[bors]

☀️ Try build successful - checks-azure
Build commit: c30cab8 (c30cab87d99b93dc2a80cda3096d1c8640ae9d44)

[rust-timer]

Queued c30cab8 with parent a5bc0f0, future comparison URL.

[matklad]

Drive by comment, but wouldn't just swapping

for constraint in outgoing_edges_from_graph.chain(outgoing_edges_from_picks)

for

outgoing_edges_from_graph.chain(outgoing_edges_from_picks).for_each(|constraint|

achieve the same effect?

[nnethercote]

@matklad: How would that help? chain is still involved. Every next() call requires two extra checks compared to a vanilla iterator. Because of this, looping over two iterators will always be faster than looping over a single chained iterator.

[matklad]

I'll tag @scottmcm who actually knows this stuff, but my understanding is that .for_each uses internal iteration for chain. That is, it doesn't call next repeteadly and compiles more like

lhs.for_each(f);
rhs.for_each(f);

I think, in the actual coude, this bottoms out in this fold override.

Because of this, .for_each is faster for chain-like iterators (and not slower for other iterator), and should be preferred in pref-sensitive code. Not that I like this state of affairs...

EDIT: cc #59740
EDIT: chain is slower in this case.

[rust-timer]

Finished benchmarking try commit c30cab8, comparison URL.

[estebank]

Other than my and @jakubadamw's nitpick, you can consider it an r+ from me.

[nnethercote]

Thanks for the various comments, I have addressed them all. @estebank, the new code is sufficiently different that you might want to take another look.

[nnethercote]

@matklad: I tried using for_each as you suggested and it slightly increased the instruction count.

[nnethercote]

It's been a few days, I'm going to carry over @estebank's earlier r+.

@bors r=estebank

[bors]

📌 Commit 5ca99b7 has been approved by estebank