gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A question on discardEventsMatchingMask:beforeEvent:


From: Fred Kiefer
Subject: Re: A question on discardEventsMatchingMask:beforeEvent:
Date: Sat, 29 Jan 2011 15:13:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11

Am 28.01.2011 15:53, schrieb Banlu Kemiyatorn:
> On Fri, Jan 28, 2011 at 5:39 PM, Banlu Kemiyatorn <address@hidden> wrote:
> 
>> (My NSApp has this implementation, allowing it to store parameters
>> instead of real event on a fixed size loop queue which can migrate old
>> event out of the fast loop queue and collect leak events and
>> auto-scale the fast loop queue to serve dense event stream over time,
>> I still need to bench a special NSEvent pool zone's thread locking
>> deallocation against the traditional event generation, hopefully this
>> evening, that would define the actual implementation of the design)
> 
> Just try benching with preallocated pool to make use of deallocated
> object w/o reallocation, it's ~160% faster than traditional +alloc. So
> my event queue would use a union for encapsulation, like XEvent.

Not using alloc/free always gives you a big benefit. The question is how
this pays out in over all memory usage.
I always wanted to use pools for a few other highly used fixed siue
object types in GNUstep, but never got around to it. My favourite at
that time was NSAffineTransform, but using our memory debugging facility
(Click on the icon in the about window of an application) shows that
even that class in rather low in the list of create temporary objects.
(Although I had about 8 time more transforms than events creates)
The objects that really would benefit from a pool are NSGDate,
GSNotification and GSMutableArray. And even there this approach might be
questionable, we first should find out, why so many of these objects get
created and whether this is really needed. My feeling here is that the
run loop is using objects on a too high level, where we could just work
without them.
As for the NSEvent class I don't see the big problem in creating and
releasing the objects, but in having to handle all the duplicate mouse
move events in an application. Before we even start to think about using
an event pool we should benchmark where the actual time gets spend and
work on that part.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]