belliottsmith commented on code in PR #7:
URL: https://github.com/apache/cassandra-accord/pull/7#discussion_r1012668795
##########
accord-core/src/main/java/accord/local/Node.java:
##########
@@ -361,8 +318,7 @@ private <T> void send(Shard shard, Request send, Set<Id>
alreadyContacted)
public <T> void send(Collection<Id> to, Request send)
{
- for (Id dst: to)
- send(dst, send);
+ to.forEach(dst -> send(dst, send));
Review Comment:
I actually expect this to be better heap-allocated than an iterator, though
I have not experimented to find out. Since `to` is an interface, the compiler
does not know what type the iterator will be.
Escape analysis doesn't operate nicely on variables that are updated, so
iirc types like iterators don't generally behave nicely. I haven't updated my
understanding in a while, in fairness, but my heuristic is that - even if the
allocation of the `Iterator` is inlined, and the foreach loop hoisted inside
the scope of the monomorphic/bimorphic call-site optimisation, the likelihood
is that the `Iterator` would not be stack allocated. However, a lambda function
is very stack-allocation friendly, as there is no internal state to update, so
the lambda may easily be stack allocated via scalar replacement. You still
require that the allocation of the lambda is hoisted inside the scope of the
monomorphic/bimorphic call-site optimisation.
We should experiment to find out.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
