It is probably actually better to have it iterative instead of recursive. The reasoning here is, calling the new version of the procedure does carry some (very small, mind you) overhead. sleeping the current stack however wouldn't have that overhead.
Both sleep() and spawn() need to schedule a stack, it's just with sleep() you're scheduling a pre-existing one, and your spawn() use must create one (and tear the old one down, when finishing).
If you do want to stick with the spawn approach, though, it may be better to use something like an event scheduler, to bunch up the scheduler use in the case of large numbers of pixel projectiles. Being biased, I recommend http://www.byond.com/developer/Stephen001/EventScheduling
If there's performance issues with it, I'm happy to work with you on that.
You should probably design your update_loop() to use an iterative approach rather than a recursive approach, as in most situations the former is faster than the latter; this may however be an exception if memoization is applied to the latter. By its very nature, recursive procedures use more memory than iterative procedures and also fills up the stack quicker, which results in a slower procedure, and even offsets(not returning what you expected) numbers sometimes.
| |
Due to the spawn(), it's not actually recursive in the classic sense. The stack won't grow, as the calls are decoupled. What you do suffer from though, is create/delete of stack frames.
| |
So I actually just tested spawn() vs while() and it turns out the spawn() is about 5-10 world.cpu faster
| |
Is this in the case of say ... 1000 of these procedures running in parallel?
| |
Interesting. I wonder why?
| |
I tried while(loc) should I try while(1)
Not sure if loc evaluating to true is slower than 1? Probably not... | |
You do have a variable access and null check there, so ... it might make some difference.
| |
There's not going to be a way to exit the while() loop without a variable check... because I'm using garbage collection for speed.
| |
I want to say using src would work for the sleep() scenario if it works for the spawn() one.
| |
The spawn version is checking for valid loc and bailing if its null every iteration...
The problem is, if I remove that check and put while(loc), it apparently isn't the same amount of computational pull (it weighs more, in that regard). Edit: Results of test cpu is the cpu usage at the time of the snapshot cpu average is the total average of the cpu at run time projectiles is the number of projectiles alive at time of snapshot projectiles fired is the total number of projectiles fired during world life bots is number of bots firing projectiles spawn method | |
I should probably post updated loop that I'm using
Here's spawn method:
proc/update_loop()Here's while method:
proc/update_loop() | |
No, because it never returns. Its just not good design in my opinion (I'm not an expert or a pro, though). I prefer a proc that exits the call stack each iteration when dealing with loops.