Now that plevent.c does its own Carbon Event stuff for PLEvent handling, we don't need the NSTimer/ProcessPendingEvents in EventQueueHandler. We should just be able to remove it.
it works, i'm doing opt builds to run page-load tests (before and after)
bad news. i turned on the carbon event code in plevent.c and removed the EventQueueHandler timer code from the toolkit and we got a big slowdown. trunk, using timer: run 1: 894 run 2: 778 trunk, using carbon events: run 1: 914 run 2: 881 run two is almost a 12% slowdown. you can see the speed difference as well while running the tests. with the timer, most pages snap in whole. with the carbon event, they come in, then jiggle once or twice. are we not handling the list of events as optimally as we should?
i even tried varying the carbon event's priority (the code on the tip uses low priority). here's what i got: using carbon events, standard priority run 1: 909 run 2: 899 using carbon events, high priority run 1: 905 *sigh* :(
I wonder if the effect of using Carbon Events in plevent.c favors a slow connection? On bug 44768, see comment 53, when I had a fast connection, and comment 65, when I had a slower connection. Either that, or it behaves differently in a Cocoa app?
It does seem to be very dependent on connection speed. Here's what I got by: removing Cache dir, and running cowtools 3 cycles CarbonEvent - avg median: 1566 Timer - avg median: 2104
I think this needs some more testing and maybe discussion. Results vary a lot depending on what speed of connection you have. If one approach can't be clearly better across the spectrum, what part of the spectrum do we aim to please?
i don't even think this bug is valid anymore, is it?
gonna give this one last shot to see what the numbers look like. i'll put a patch up shortly.
we're gonna leave this as-is for now and investigate ways that aren't so tied up in the event loop and jockeying for position with redraw events, etc.
i think we can safely dupe this to 271050. please comment over there. *** This bug has been marked as a duplicate of 271050 ***