[Openmcl-devel] Re: Hemlock performance investigation

[Hamilton Link]

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

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  
somewhat-larger files).

I will see if I can squeeze this in this weekend.

h