Having not seen the patch, it sounds like you changed the "scheduler" to be more "round robin" between input and timers, and that's fine.
That part is ok but I am still concerned about rapid fire timers.

> Since some of these timers aren't for visual effects (polling, checking

Is there really a site that *needs* timers faster than 500ms for nonvisual purposes?
Kevin you've combed through the acid tests, is this a concern?

1. I suppose I have a general concern about resources, edbrowse will never be optimized the way chrome is, it's already slow, if we have a dozen such sites up with these timers, some of them pushed onto the stack so we don't even see them, and they're all running at this rapid rate, I can picture the load average climbing up above 3.

2. I live and die by db5. I couldn't have gotten this far debugging without db5.
Each timer produces a lot of debugging output. Some of this is overhead just to run the timer.
Did the user change one of the input fields, and do we have to push that change down to the js world before we run the js timer, and when we get back is there stuff we have to do?
Trust me it makes a lot of output.
If that flies every ten seconds it's prohibitive on the screen, and even when redirected into a debug file, the file is huge in a matter of a second.
And it might take several seconds to set up the condition I'm trying to debug.
Then I have to slog through a 100 megabyte file to find the problem.
So that's a concern to me.
I imagine you could let timers fly at db2 or less, and cap them at 600ms for db3 or higher (my cap is 600ms across the board today), but that means db2 and db3 run differently and that has its own concerns.

3. Edbrowse doesn't garbage collect at all. html tags keep accumulating.
Look at www.eklhad.net/async. It updates the page once a second via innerHTML.
On the js side, new objects are created, and the old ones go away via gc.
On the edbrowse side, new tags are created, and the old ones are marked dead when js removes the corresponding objects, thanks to Dominique's clever trick, but the old tags don't go away, they just sit there dead.
This is something we may need to address at some point, it's just not there today.
So memory will grow very quickly at 10ms, and not just memory, because a lot of the code simply scans through those tags linearly, so edbrowse will bog down very quickly.
Knuth would frown on a lot of this code, but it is what it is.
I don't think we can or should run high timers until this issue is addressed.

Push the round robin if you like, but I wouldn't ratchet the timers up to high just yet, or maybe make the cap a global variable that we can change in various circumstances, or set in the config file, or otherwise have some control over.
Perhaps the foreground window runs fast and all other edbrowse windows are throttled, or based on debug level, or slow down after we have 5000 tags, IDK.

Thanks for looking into this.

Karl Dahlke