[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] fastevent example/test not so fast.

IIRC, the other advantage to the fastevent system is that it's guaranteed to never lose events (because it will run into a lock and hang until there's room), where SDL events live in a fixed sized bucket. I think that's why I put it in there, to ensure that Twisted's threadedselectreactor will work correctly (because it depends on the guarantee that all messages will be received and handled by the main thread).

I don't really have time to mess with it, unfortunately.

-bob

On Aug 2, 2005, at 1:34 PM, Rene Dudfield wrote:

hrmm.  I made the example use a thread.  So pretty much like the
example on the fastevent site said.

Maybe since that guy has tested it, the standard sdl event stuff has
gotten faster?

Bob, do you reckon you could have a play with the example?

Cheer.



On 8/2/05, Bob Ippolito <bob@xxxxxxxxxx> wrote:


On Aug 1, 2005, at 8:51 PM, Marcus von Appen wrote:


On, Tue Aug 02, 2005, Rene Dudfield wrote:



I wrote a new example for pygame.fastevent.  However it seems that
fastevent is actually slower than the normal event functions.  Only
tested on windowsXP so far, cause my linux machine isn't in a
state to
compile pygame.



Tested on FreeBSD 5-Stable (P4 2.8 Ghz, 512 MB Ram). Using the
fastevent
module, the events per second are pending around 41600. If I
disable it
in the example, the events per second are pending around 45600.  So
the
fastevent module actually is not fast ;-).


It should be for multithreaded applications.  That's what it's
designed for, anyway.

-bob