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

[David Chisnall]

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.

David

-- Sent from my IBM 1620