Re: objective-c: how slow ?

[Marko Mikulicic]

Erik M. Buck wrote:
> > Do you think that doubling the performance of message dispatch for common
> > targets will speedup the gui (responsivness) ?
>
> Probably not when you consider that the processor time to draw the pixels of
> a button completely dwarfs the processor time used performing that action of
> the button in most cases.  There is no hardware acceleration for Quartz.  If
> we really want to speed up the GUI in OSX, I suspect the best approach would
> be to double the bus bandwidth between main memory and graphics memory.

You're right,
MacOSX wastes (this is an opinion) memory bandwidth and computing power
(I guess menu transparency is not hardware accelerated, at least not all).
I thought of a more calm GNUstep with standard style running on modest linux
box (say at 300 MHz, to be modern). I personally don't like to assume that every 
year everyone will upgrade to the last tehnology the market offers.
 However, I was interested in the processing of events and notifications, when
managing very conplex gui, not the drawing of pixels, which isn't really a 
matter of objc.
 I noticed writing qt applications (C++) that when the connections grows in size
the application become quickly unresponsive (that's bad design caused by C++)
(~30k lines, mostly gui). I used extensively the signal/slot facilities of that
framework, which are similar to notifications in gnustep. Qt reinvents the wheel 
of dynamic dispatch, which gnustep handles natively, and thus my belief that
gnustep will not suffer the same bottleneck. I don't understand yet very well 
the gnustep internals, but it seemed to me that the notification mechanism is 
widespreadly used in the gui code.


Marko