197889 - Remove EventQueueHandler stuff from Cocoa nsToolkit

Status: RESOLVED DUPLICATE of bug 271050

(Camino Graveyard :: General, defect)

Description

[Simon Fraser [no longer active]]

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.

Comment 1

[Mike Pinkerton (not reading bugmail)]

it works, i'm doing opt builds to run page-load tests (before and after)

Comment 2

[Mike Pinkerton (not reading bugmail)]

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?

Comment 3

[Mike Pinkerton (not reading bugmail)]

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* :(

Comment 4

[Conrad Carlen (not reading bugmail)]

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?

Comment 5

[Conrad Carlen (not reading bugmail)]

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

Comment 6

[saari (gone)]

->ccarlen

Comment 7

[Conrad Carlen (not reading bugmail)]

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?

Comment 8

[Mike Pinkerton (not reading bugmail)]

i don't even think this bug is valid anymore, is it?

Comment 9

[Mike Pinkerton (not reading bugmail)]

gonna give this one last shot to see what the numbers look like. i'll put a
patch up shortly.

Comment 10

[Mike Pinkerton (not reading bugmail)]

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.

Comment 11

[Mike Pinkerton (not reading bugmail)]

i think we can safely dupe this to 271050. please comment over there.

*** This bug has been marked as a duplicate of 271050 ***