[Openmcl-devel] Re: Hemlock performance investigation

[Gary Byers]

On Wed, 25 Aug 2004, Hamilton Link wrote:

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

I think that the cache-related stuff is probably having a significant
impact, but the biggest culprit Shark found was in code that tries to
determine whether an arbitrary pointer is an ObjC instance.  Every
time the characterAtIndex: callback is called, we have to figure out
that the SELF pointer is a HEMLOCK-BUFFER-STRING.  If we know for sure
that a pointer is an ObjC instance, determining its class is pretty
simple.  If we don't know that for sure, we have to do some heuristic
tests (is it in an ObjC section in a library ? is it malloc'ed, and
of reasonable size ?) that're fairly expensive for something called
as often as characterAtIndex: (which calls HEMLOCK-CHAR-AT-INDEX,
which calls UPDATE-LINE-CACHE-FOR-INDEX) is.

We know that SELF in an ObjC instance method is an instance, and
we know that anything declared to be of type ID (any parameter or
return value) is either an instance, class, or metaclass.  That
should enable us to skip the heuristic checks and determine the
pointer's class.

Every time the callback is invoked, SELF is a new, untyped MACPTR.
When we call an accessor method on it (to get the cache associated
with the string), we have to determine that pointer's class.  For
many method calls, the expense of doing that is relatively small;
for characterAtIndex:, it seems to be more significant.