Re: NSAttributeString source code....

[Lars Sonchocky-Helldorf]

Am 06.06.2006 um 17:26 schrieb Richard Frith-Macdonald:

> On 2 Jun 2006, at 10:24, Lloyd Dupont wrote:
>
> > In NSAttributedString I found the following code (snippets)
> > ======= NSAttributedString.m (snippets) ==============
> >
> > static SEL getSel;
> >
> > @implementation NSAttributedString
> >
> > + (void) initialize
> > {
> >  if (self == [NSAttributedString class])
> >    {
> >      getSel = @selector(attributesAtIndex:effectiveRange:);
> >    }
> > }
> >
> > - (NSDictionary*) attributesAtIndex: (unsigned int)index
> >       longestEffectiveRange: (NSRange*)aRange
> >       inRange: (NSRange)rangeLimit
> > {
> >  NSDictionary *attrDictionary;
> >  IMP  getImp;
> >
> >  getImp = [self methodForSelector: getSel];
> >  attrDictionary = (*getImp)(self, getSel, index, aRange);
> >  return attrDictionary;
> > }
> > @end
> >
> > ===========================================
> >
> > Now I wonder.....
> > Why in Hell write that?
> >
> > I mean what's wrong with:
> >  attrDictionary = [self attributesAtIndex: index effectiveRange:  
> > aRange]
> > Why replace it by:
> >  static SEL getSel;
> >  getSel = @selector(attributesAtIndex:effectiveRange:);
> >  getImp = [self methodForSelector: getSel];
> >  attrDictionary = (*getImp)(self, getSel, index, aRange);
> >
> >
> > Yes, why????
> > why GNUstep code work so hard at being so obscure???
>
> Well if the code was as listed above it would be really stupid ...  
> but of course it's not.
>
> In fact the call to (*getImp)(self, getSel, index, aRange) is done  
> inside a loop and might get called a lot of times.
> Where the attributed string is actually a large document that can  
> make a significant difference to performance by removing method  
> lookup overheads.

wouldn't some comments in the code at such places make things a lot  
clearer? A simple

// caching for perfomance

would have avoided some confusion and would definitely help newcomers  
to get easier access to GNUstep coding. Otherwise it looks like  
voodoo and confuses people. Some short comments on obscure place  
sometimes help a lot. You don't need to write novels. Easy access to  
the code is important to involve more developers.

> Most (maybe all) cases where the code caches method implementations  
> are for situations where it's been tuned for performance because  
> the method call overheads were becoming an issue.  By the nature of  
> things this needs to be done mostly in heavily used parts of the  
> base library ... and the fact that it's done there does *NOT* in  
> any way imply that it's sensible to do that sort of thing routinely  
> in applications (or other libraries).  That is to say, the base  
> library source is a good example of how to write a base/foundation  
> library, not a good example of how to write general code.  I almost  
> never cache method implementations in my appllication code.

regards, Lars