Jakub Dóka

@thomaseizinger the https://github.com/libp2p/rust-libp2p/actions/runs/9389775529/job/25864640742?pr=5026 is failing but I most likely did not cause it since swarm is not even imported, it might be the cargo lock update though

that was the problem, scarry

> This looks great! Thank you very much. > > We have some automation that will use the text in `## Description` in your PR as the commit message for...

After some more research... I found out bottleneck is where is should be, I mistook the instruction for something else, so excessive polling most likely does not happen, consider this...

@mxinden should I make a small pr that fixes the https://github.com/libp2p/rust-libp2p/issues/4284. Disadvantage of the fix is that the `libp2p_swarm::handler::ProtocolChange` changes from difference iterator to owned `SmallVec` since the iterator is...

> > Disadvantage of the fix is that the `libp2p_swarm::handler::ProtocolChange` changes from difference iterator to owned `SmallVec` since the iterator is set specific and borrowed, so that prevents me from...

I discovered quite the opposite problem when experimenting with optimized polling. Without proper waking in my handler, the whole swarm gets stuck because connection event does not cause a repoll...

You can find all reasoning in code.

I did not realize you are actually rebuilding the tree each frame. Yes it is faster. ## reasoning Entities does not change quadrant very often and update does mostly noting...

> Can't the current implementation support that just as well? Updating doesn't matter for stationary objects. As you stated you are cleaning quadtree each frame and reinserting all objects. If...