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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
