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
_______________________________________________
Edbrowse-dev mailing list
Edbrowse-dev@lists.the-brannons.com
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Reply via email to