The two main hogs in the test suite are collapse long, and cute train, both characterised by crazy-big maps.
Possible avenues:
Some better spatial partitioning than my current row/column estimates might be in order (on the other hand - collapse at least does involve mass application of rules -the data isn't sparse, so maybe it's not so useful)
again causing a full resimulation doubles the turn length - I don't see an easy workaround for this, however
rule application happens a lot in these ones, there are many matches, so the following functions might be improveable
-Rule.prototyp.applyAt
-CellPattern.prototype.replace
-generateTuples
i can also imagine things like
"well if you're using again to look ahead a turn and nothing happens, you can cache a lot of the data you used for that (like the row/column masks, which takes about 10% of the time to calculate)"
also the fact that, for again, if you have simulated the next turn, and something happens, you probably want to just remember what that state is rather than recalculating it again when the tick happens (though you'll be interested calculating the future frame then). (This would mess with the examples in the test suite that mix random and again, so they'd have to be recorded, but no big deal)
increpare
commented
7 years ago
The two main hogs in the test suite are collapse long, and cute train, both characterised by crazy-big maps.
Possible avenues:
Some better spatial partitioning than my current row/column estimates might be in order (on the other hand - collapse at least does involve mass application of rules -the data isn't sparse, so maybe it's not so useful) again causing a full resimulation doubles the turn length - I don't see an easy workaround for this, however rule application happens a lot in these ones, there are many matches, so the following functions might be improveable -Rule.prototyp.applyAt -CellPattern.prototype.replace -generateTuples
i can also imagine things like "well if you're using again to look ahead a turn and nothing happens, you can cache a lot of the data you used for that (like the row/column masks, which takes about 10% of the time to calculate)"
also the fact that, for again, if you have simulated the next turn, and something happens, you probably want to just remember what that state is rather than recalculating it again when the tick happens (though you'll be interested calculating the future frame then). (This would mess with the examples in the test suite that mix random and again, so they'd have to be recorded, but no big deal)