Fwd: [Openmcl-devel] Re: Hemlock performance investigation

[Hamilton Link]

OK, the following addition by Gary (can't hardly go to bed late enough 
or get up early enough to keep up with that guy) makes layout WAY 
faster, when the file is opened and just in general. So typing is 
lickety-split now and maybe Gary won't have to get coffee when hemlock 
is opening large files any more. Thanks Gary and thanks to all that 
provided quality pointers into the Cocoa documentation (he says, as he 
turns around and does a random insertion of said material into his in 
box).

As per previous discussion with Alex, now that the performance is 
palatable, the various missing function bindings, etc. that cause the 
panic sheet to pop up need to be attacked. This might be a team effort, 
if you find time to implement a function here or there in the list of 
undefined functions that are announced when hemlock is first compiled, 
post it to GB (and copy me for testing).

Once the editor is more stable we can start binding keys to open other 
widgets (inspector, backtrace, etc.) and add/improve/integrate 
additional functionality beyond the editor and listener.

And thanks to the pointer for the link on hemlock docs, I'll peek at 
those. At one time GB had a webkit window working from hemlock, popping 
that up with a window into some chunk of hemlock docs, openmcl web 
docs, or the hyperspec might be cool for help-related functionality.

h

Begin forwarded message:

> From: Gary Byers <gb at clozure.com>
> Date: August 28, 2004 1:42:41 AM MDT
> To: Hamilton Link <hamlink at comcast.net>
> Subject: Re: [Openmcl-devel] Re: Hemlock performance investigation
>
>
>
> On Sat, 28 Aug 2004, Hamilton Link wrote:
>
>>
>> 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.
>
> I implemented getCharacters:range: a few minutes ago.  The text system
> seems to want to grab up to 64 characters per call to
> getCharacters:range:, which (according to my calculations) makes
> things about ... 64X faster (or at least avoids the
> characterAtIndex:-like overhead 63 times.)  I'll see if 64 is a
> tunable parameter or hardwired; even if this "only" speeds things up a
> few dozen times, it seems like a win.
>
> (define-objc-method ((:void :get-characters (:address buffer)
>                             :range (:<NSR>ange r))
>                      hemlock-buffer-string)
>   (let* ((cache (hemlock-buffer-string-cache self))
>          (index (pref r :<NSR>ange.location))
>          (length (pref r :<NSR>ange.length))
>          (hi::*buffer-gap-context*
> 	  (hi::buffer-gap-context (buffer-cache-buffer cache))))
>      #+debug
>      (#_NSLog #@"get characters: %d/%d"
>              :unsigned index
>              :unsigned length)
>   (multiple-value-bind (line idx) (update-line-cache-for-index cache 
> index)
>     (let* ((len (hemlock::line-length line)))
>       (do* ((i 0 (1+ i))
>             (p 0 (+ p 2)))
>            ((= i length))
>         (cond ((< idx len)
>                (setf (%get-unsigned-word buffer p)
>                      (char-code (hemlock::line-character line idx)))
>                (incf idx))
>               (t
>                (setf (%get-unsigned-word buffer p)
>                      (char-code #\Newline)
>                      line (hi::line-next line)
>                      len (hi::line-length line)
>                      idx 0))))))))
>
> It might speed things up a bit to leave the cache pointing at the end
> of the range we just processed.  If you enable the #_NSLog, you may
> see that it asks for 64 characters at 60-character increments; it
> seems kind of hard to optimize for that case.
>