What was the rationale behind this?

https://trac.wildfiregames.com/ticket/5979
If we don't need to keep serialising data that is unused for large amount of time, e.g. OOS logs become (a tad) more readable.

Are there things I am overlooking here?

To not just complain, I like these changes.

Maybe explicitly defining serializable properties might be cleaner. And if performance is the concern, setting a boolean is definitely faster than deleting properties and re initializing them again. There is also the issue of type optimizations potentially.

Potential performance impacts would depend on the JS engine, but I recall from some earlier benchmark that delete was kinda expensive since further lockups would result in searching the prototype chain. Also, it might change the object layout. Moreover, SM JIT does not play well with delete on arrays and hitting array holes was like hitting a wall. Given the underlying JS array implementation, I would not be surprised if the same behavior was found in objects as well.

I haven't redone those tests in current SM version. So, take that however you will.

Thanks for your insights!

I actually thought that delete-recreate was slower than resetting, but reasoned that in cases like this (blocked spawning doesn't happen often) it is better than keeping a variable for the entire length of the game.
That said, I did not think of lookup costs. I'll post your thoughts on the ticket as well.

I remember those points too, though perhaps not in such detail. IIRC delete played badly with the JIT in general, but we lack good tools to measure that currently anyways.

I'd agree in general that I think it's OK for 'rare' properties - I'd say here qualifies. Still, caution seems good, but I don't think this particularly needs changing.

IMO our lack of good tooling in current SM with regards to profiling this makes it somewhat moot. I doubt the real slowdowns are in these micro-optimisations very much.

I don't think there are that much "really slow" functions in JS. Just a lot of "somewhat slow" adding up.

Most of these benchmarks were done back then for map generation code where this was found to be extremely true.

(I have no clue about JS simulation performance though and never checked either)