The command stack should be optimized #50

New Issue

scott · 2025-07-01T19:43:52Z

scott commented

2025-07-01 19:43:52 +00:00

If a turtle is "walking" in a straight line, say, 4 pixels per tick for 100 pixels, we would end up telling p5 to draw 25 4px lines instead of one single 100px line. This is inefficient.

It's reasonably easy to do the math here, so do it. (In pkg/ludus.js.)

If a turtle is "walking" in a straight line, say, 4 pixels per tick for 100 pixels, we would end up telling p5 to draw 25 4px lines instead of one single 100px line. This is inefficient. It's reasonably easy to do the math here, so do it. (In `pkg/ludus.js`.)

scott added the

optimization

label 2025-07-02 16:06:22 +00:00

scott added this to the Post-CC2 milestone 2025-07-02 17:18:07 +00:00

scott commented

2025-07-10 02:36:08 +00:00

I believe this is actually what's at issue behind the performance issues with this sketch

I believe this is actually what's at issue behind the performance issues with [this sketch](https://web.ludus.dev/?code=fn+mover+%28%29+-%3E+%7B%0A++receive+%7B%0A++++%22w%22+-%3E+forward%21+%280.01%29%0A++++%22a%22+-%3E+lt%21+%28inv+%2836000%29%29%0A++++%22s%22+-%3E+back%21+%280.01%29%0A++++%22d%22+-%3E+rt%21+%28inv+%2836000%29%29%0A++%7D%0A++mover+%28%29%0A%7D%0A%0Alet+move+%3D+spawn+%28mover%29%0A%0Afn+listener+%28key%29+-%3E+%7B%0A++if+key_down%3F+%28key%29%0A++++then+send%21+%28move%2C+key%29%0A++++else+nil%0A++yield%21+%28%29%0A++listener+%28key%29%0A%7D%0A%0Alet+d_listener+%3D+spawn+%28fn+%28%29+-%3E+listener+%28%22d%22%29%29%0Alet+a_listener+%3D+spawn+%28fn+%28%29+-%3E+listener+%28%22a%22%29%29%0Alet+w_listener+%3D+spawn+%28fn+%28%29+-%3E+listener+%28%22w%22%29%29%0Alet+s_listener+%3D+spawn+%28fn+%28%29+-%3E+listener+%28%22s%22%29%29%0A%0Ahibernate%21+%28%29)

scott referenced this issue

2025-07-11 18:41:32 +00:00

Keyboard interaction should work #94

scott commented

2025-07-11 19:35:42 +00:00

In place of paths being more efficient, we've decided that it's easier/better to make commands more efficient: squash the commands when we ask for them, instead of doing it when we calculate the p5 path.

In addition, the idea is that we need to cache the already-squashed commands, so that we're not crawling the whole stack each time. Also: we can implement clear this way. This will be a more thoroughgoing refactor than I had hoped, but should make this much more performant.

In place of paths being more efficient, we've decided that it's easier/better to make _commands_ more efficient: squash the commands when we ask for them, instead of doing it when we calculate the p5 path. In addition, the idea is that we need to cache the already-squashed commands, so that we're not crawling the whole stack each time. Also: we can implement `clear` this way. This will be a more thoroughgoing refactor than I had hoped, but should make this _much_ more performant.

scott changed title from ~~Paths should be (more) efficient~~ to The command stack should be optimized

2025-07-11 19:36:03 +00:00

Sign in to join this conversation.