You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If Paws is ever to be remotely performant, then the (many) lowest-level operations, constructed libside as Executions, need to be evaluated without every single combination causing the operation to be unstaged, and then cause it to sit through the reactor queue again.
Clearly, it's desirable that a truly basic series of operations on objects without overriden receivers be processable by optimised implementations during a single reactor-tick …
… but that raises a huge question: how can we allow such a series of operations to safely jump the reactor queue? The queue maintains order-of-operations; and if any operation is allowed to jump that queue in any situation, that operation could theoretically be out of order. (Not to mention fucking up mutability-safety by skipping the responsibility checks, eh?)
So: this needs thinking-through, to figure out if it's actually dangerous; and then, hopefully, munging-up of the design until we can safely do this. (I'm willing to make some small concessions at the design level for this, despite compramising on the design for the sake of performance being generally against my principles, because this is clearly one of the biggest bottlenecks in the entire design. Could easily find one extremely common ‘operation’ taking ten, or even fifty, ticks, instead of one or five. Ick.)
The text was updated successfully, but these errors were encountered:
If Paws is ever to be remotely performant, then the (many) lowest-level operations, constructed libside as Executions, need to be evaluated without every single combination causing the operation to be unstaged, and then cause it to sit through the reactor queue again.
Clearly, it's desirable that a truly basic series of operations on objects without overriden
receiver
s be processable by optimised implementations during a single reactor-tick …… but that raises a huge question: how can we allow such a series of operations to safely jump the reactor queue? The queue maintains order-of-operations; and if any operation is allowed to jump that queue in any situation, that operation could theoretically be out of order. (Not to mention fucking up mutability-safety by skipping the responsibility checks, eh?)
So: this needs thinking-through, to figure out if it's actually dangerous; and then, hopefully, munging-up of the design until we can safely do this. (I'm willing to make some small concessions at the design level for this, despite compramising on the design for the sake of performance being generally against my principles, because this is clearly one of the biggest bottlenecks in the entire design. Could easily find one extremely common ‘operation’ taking ten, or even fifty, ticks, instead of one or five. Ick.)
The text was updated successfully, but these errors were encountered: