Re: A question on discardEventsMatchingMask:beforeEvent:

[Richard Frith-Macdonald]

On 28 Jan 2011, at 14:53, Banlu Kemiyatorn wrote:

> 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.

For sure the biggest problem with events in GNUstep (which made us need to 
combine them in the backend) was performance even when just dragging the mouse, 
and most of the issue was with the allocation/deallocation of NSEvent objects.  
I considered trying to improve that a few years ago, so I'm not surprised that 
you can get a huge performance improvement using an alternative allocation 
scheme.
When I was looking at it, I found it hard to see how best to make a fast 
allocation/deallocation scheme thread-safe.
You might also want to consider the idea of making the event queue a linked 
list rather than a mutable array implementation.