[Openmcl-devel] Hemlock performance investigation

[Hamilton Link]

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.

h

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 
>> text
>> 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.)
>
>> thanks,
>> hamilton
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>