[Openmcl-devel] Hemlock performance investigation
hamlink at comcast.net
Wed Aug 25 21:09:31 PDT 2004
Metering and watching text very slowly crawl across the screen,
mark-absolute-position takes about 3.8e-4 seconds per invocation, and
in typing several lines of text in several places, it got called 182
times (for a total of 70ms, as far as cumulative differences in
get-internal-real-time across the calls).
I think it's safe to say mark-absolute-position is not the culprit.
update-line-cache-for-index chews up 0.996 seconds just opening a
908-line file... and in the course of typing a very slow half line of
text it uses up 1.735 seconds. That's not huge, and individual calls
hardly register, but it's being called INSANELY often, like a few
hundred thousand times as far as I can tell in the course of typing a
few lines. Is this really, really bad?
one place it gets called from is hemlock-char-at-index, which total
time in the course of a slow, slow line takes up 4.054 seconds... this
is very suspicious and I bet it's where update-line-cache-etc is being
called so many times from. Question: is this a function that ObjC would
do as a callback, and would repeated calling of this (in the many tens
of thousands, presumably for checking that nothing has to be redrawn)
crossing the objc bridge suck up a lot of time?
off to play.
On Aug 25, 2004, at 8:24 AM, Gary Byers wrote:
> On Tue, 24 Aug 2004, Hamilton Link wrote:
>> I would be a little surprised if there was a Mac OS issue here...
>> particularly because in a fresh cocoa listener window there is no
>> perceptible delay, while in a medium-sized lisp file there's a big
>> honkin' delay. Cocoa issues wouldn't be affected by the file size,
>> where the rest of this could. On the other hand, maybe it's just much
>> easier for Cocoa to figure out what to be redrawing when the whole
>> wrapper object is smallish.
>> We'll see. I will spend some time looking as well, I'll do some
>> profiling of Gary's suspects to start with. Where in the lisp by the
>> way are you looking, again? I'd like to profile those points as well.
> One other suspect that I may not have mentioned explicitly is
> CCL::MARK-ABSOLUTE-POSITION, which doesn't even try to exploit the
> cache (it just walks preceding lines until it reaches the beginning
> of the buffer.) How long this takes is obviously a function of how
> many preceding lines there are.
> If this (and gratuitous invalidation of the line<->position cache)
> were a factor, editing at the beginning of a large buffer would be
> more responsive than editing at the end. (Doing MARK-ABSOLUTE-POSITION
> naively and invalidating the cache at the drop of a hat can't be Good
> Things, whether they're smoking guns or not.)
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel