[Openmcl-devel] Re: Hemlock performance investigation
hamlink at comcast.net
Sat Aug 28 03:04:27 EDT 2004
>> Would the buffer happen to be one monolithic Unicode NSString (or is
>> something expecting to be accessing an NSString)? If so, O(n)
>> accesses occur for every call to character-at-index since this is
>> Unicode. It has to walk the entire string from the beginning since
>> the size in bytes of a character is not fixed. If you scan every
>> character in the file, then that is also O(n).
> This certainly might be the culprit. Quoting the NSString
> - (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
> The abstract implementation of this method uses characterAtIndex:
> repeatedly, correctly extracting the characters, though very
> inefficiently. Subclasses should override it to provide a fast
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.
Specializing get-characters is necessary and should speed up initial
layout and re-layout, but mind you this still won't make things less
than linear, it will just be a faster linear. Disabling background
layout during most of editing is probably a better way to go (given
that even a several-times speedup would only prevent the problem up to
I will see if I can squeeze this in this weekend.
More information about the Openmcl-devel