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

[Fred Kiefer]

David Chisnall schrieb:
> 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).
> 

As far as I remember, the text system uses IMP caching at two places. In
GSHorizontalTypesetter and in NSGlyphGenerator. These two are central
parts of the layout system that need to be fast. But of course GNUstep
has changed since the time these bits were written. Perhaps the three
method calls that had been optimized into function calls don't make that
much difference any more. At least at the time when the optimisation was
done there were hard figures that suggested this to be worth while.
Do you have any numbers that say so or is this just general ranting
against premature optimisation? The later I support whole heartedly.

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

I never understood why we do this.

Fred