Why does this line ruin the performance?

[rsalmei]

Hey folks, a little help please…
I'm moving the border drawing from the Game into the Board struct. This will allow me to dynamically change the border, like opening holes in it, where the balls could wrap around.

Well, I’m drawing it around the board, so there’re two for’s, which draw four straight lines, top/bottom and left/right.
The total render time is sub-millisecond most of the time now, but if I uncomment any of the horizontal lines, it skyrockets up to 16ms 😱!! And varies wildly…

https://github.com/rsalmei/ballbounce/blob/timing-conundrum/src/board.rs#L17-L25

How could that be, what is happening? Would someone have a clue?
Here is a short video of the total frame render times, without any of those lines and uncommenting only the first one:

ballbounce.border.time.mp4

[txai]

Horizontal lines seems to be a major portion of your framebuffer, making it huge, as you uncomment those 2 lines.
That said, I did some measurements and found the costly lines are
let old = self.data_back.keys().collect::<HashSet<_>>();
let new = self.data.keys().collect::<HashSet<_>>();
and
let old = self.data_back.iter().collect::<HashSet<_>>();
let new = self.data.iter().collect::<HashSet<_>>();
Since each pair consumes from 0,8 to 2ms
You can modify the display_clear signature and implementation slightly to match that of display_buffer, and by doing so you can get rid of the first problematic pair, you'll get some improvement in performance.
You can probably also draw the board only if an event occur, like some ball hitting the wall and making it disappear. This would have a major impact in performance, I guess, because the board doesn't change so often as the balls

[rsalmei]

Hey @txai, thank you!
But I just realized I had messed up that branch, where I show this problem, my bad...

And thank you on the analysis of the new code! Surely I can improve it, I'll read your comment again, but it should probably be in another issue...

Anyway, I did fix the branch code, now you can see what were that weird performance issue... Thanks!

[rsalmei]

Just for the record, I think the performance currently is awesome!
Look at this, I put 320 moving objects on screen, and it uses only ~2ms.
With the default 20 objects it is sub-millisecond (and those two lines which draw the border are here).

Screen.Recording.2021-05-28.at.20.46.55.mov