[Top][All Lists]

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

Re: Changes I've been thinking of...

From: David Chisnall
Subject: Re: Changes I've been thinking of...
Date: Thu, 8 Oct 2009 17:43:55 +0100

On 8 Oct 2009, at 17:16, Derek Fawcus wrote:

[trimmed out the discuss list]

On Thu, Oct 08, 2009 at 03:42:38PM +0100, David Chisnall wrote:

[on gui]

There are also some plainly embarrassing bugs, like the fact that underlining still doesn't work.
Useful to know,  I was about to try using it :-)

Apparently it wasn't done because doing it 'the right way' is hard, and although just using an NSBezierPath to draw a line under the glyph run would be trivial for anyone who understands the text system, it wasn't done because it's not 'the right way.' No one who knows what 'the right way' of doing it is was available for comment, unfortunately.

Much of the text system code is in need of an overhaul, because it's currently a mess of premature optimisation that none of the current developers actually understands.

Because of the program I'm hacking on, I've been reading through quite a bit of the Text System code lately. I did notice a lot of SEL/Imp caching going on. I seem to recall that your new runtime was/is supposed to improve this. Would it allow these optimisations to be reverted?

SEL caching is always pointless from a performance perspective. @selector() directives are evaluated at load time and are uniqued on a per-compilation-unit basis. The only reason for caching @selector() expressions is to eliminate the kind of bug where you make a typo in @selector() in an infrequently-used code path and a frequently-used one, then fix it in one place and not the other.

IMP caching is a bit more complicated. The new runtime supports a means of invalidating IMP caches, which means that the compiler will be able to automatically insert (polymorphic) IMP caching and even speculatively inline methods. Doing this well will require profiling (I have written an LLVM pass that adds profiling information to the code, but not one that uses this information to add the caching yet). To use this in the text system, we'd want to add a set of automated test programs using a null back end that would generate profiling information for how the text system is typically used and then compile an optimised version.

To be honest, I suspect that most of the places where the text system currently does IMP caching are completely irrelevant. I've been playing with implementing some of the algorithms from LaTeX in Objective-C recently, and the overhead from message sends is largely irrelevant, especially when you compare it to the overhead in drawing an antialiased glyph (although, if you're lucky, the GPU will do most of that for you).

There are lots of places where GNUstep is guilty of premature optimisation. Another example is that a lot of classes call NSDeallocateObject(self) rather than [super dealloc], which has a negligible performance impact but breaks any category that tries to replace NSObject's dealloc method.


-- Sent from my IBM 1620

reply via email to

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