[Openmcl-devel] Re: Hemlock performance investigation

[Gary Byers]

On Sat, 28 Aug 2004, Hamilton Link wrote:

> >
> > This certainly might be the culprit.  Quoting the NSString
> > documentation:
> >
> > http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
> > ObjC_classic/Classes/NSString.html#//apple_ref/doc/uid/20000154/
> > getCharacters_range_
> >
> > getCharacters:range:
> >
> > - (void)getCharacters:(unichar *)buffer range:(NSRange)aRange
> > Copies characters from aRange in the receiver into buffer, which must
> > be large enough to contain them. Does not add a zero character. Raises
> > an NSRangeException if any part of aRange lies beyond the end of the
> > receiver.
> >
> > The abstract implementation of this method uses characterAtIndex:
> > repeatedly, correctly extracting the characters, though very
> > inefficiently. Subclasses should override it to provide a fast
> > implementation.
>
> By now you have seen that hemlock-buffer-string is a subclass of
> ns-string, so I agree this should be a way to make layout faster.
> Disabling background layout solves the problem completely, and if
> layout calls this or (more likely) getCharacters, that would explain
> everything we are seeing. Good find.

One of the principle callers of "characterAtIndex:" (or
"getCharacters:range:") in the text system is
"getLineStart:end:contentsEnd:forRange:", which is basically used to
find the indices where lines start and end.  (This is at least a
"principal caller" during initial text layout, where there are
presumably lots of reasons for wanting to know where lines start
and how many lines there are, etc.)

The default implementation reads characters (via "characterAtIndex:"
or a specialized "getCharacters:range:" if it's available) until it
finds a line- terminating character (or CRLF).  Since the underlying
Hemlock buffer is a doubly-linked list of lines with implicit
#\Newlines between them, we can generally do better than the default
implementation in this case.

I would guess that there may be at least a few other NSString
(NSMutableAttributedString, etc.) methods where a specialized
Hemlock-aware version would be much better than defaulting to
the generic version has been.