Jeff Clites <[EMAIL PROTECTED]> wrote: > On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote:
> What I meant was, _every_ backward branch (etc.) in the bytecode, or > just one location that we thought would execute "soon". (But you > implicitly answered this, below.) Every backward branch. Guessing the PC and patching in front of that can't work. >> But we can of course measure how long it takes to patch a certain >> amount of code twice. > It just seems bad that the efficiency of event delivery would be > proportional to the size of the bytecode (or segment). So it's slower > to deliver events in large programs. That seems like a bad omen. It depends, how bad it really is: - it should be possible, to patch only the current subroutine, which might or might not help (a Sub can still be huge). The program flow can't have left the Sub in the meantime, because: - a bunch of opcodes (sleep, invoke*) will check events explicitely (this is the original strategy) - the problem is of course loops, that don't have any explicit check event opcode inside. For these there are 2 strategies: a) the event handler thread patches these backward branches or b) the backward branch op checks for events always Both have some costs: a) means slower event delivery, b) means slower execution in the absence of events. If patching takes too long, we can't do it and have to use b) that's it. The negative performance impact of b) can be reduced somtimes by partial loop unrolling. As said, we have to benchmark all. > JEff leo
