Fwd: [Openmcl-devel] Re: Hemlock performance investigation
hamlink at comcast.net
Sat Aug 28 12:00:43 EDT 2004
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
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.
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))
> (let* ((cache (hemlock-buffer-string-cache self))
> (index (pref r :<NSR>ange.location))
> (length (pref r :<NSR>ange.length))
> (hi::buffer-gap-context (buffer-cache-buffer cache))))
> (#_NSLog #@"get characters: %d/%d"
> :unsigned index
> :unsigned length)
> (multiple-value-bind (line idx) (update-line-cache-for-index cache
> (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))
> (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.
More information about the Openmcl-devel