[Openmcl-devel] Re: Hemlock performance investigation

[Hamilton Link]

We have a winner!

*character-at-index-callback*: 20.995 seconds
*hemlock-char-at-index*: 5.06 seconds
*update-line-cache-for-index*: 1.411 seconds
*mark-absolute-position*: 0.021 seconds
*reset-buffer-cache*: 0.014 seconds
*move-hemlock-mark-to-absolute-position*: 0.001 seconds

So, a couple more questions for the panel:
- can we set up something in the ObjC world so that this specific 
callback is invoked less (crossing the FFI boundary can't be all that 
great to begin with) than the hundreds of thousands of times that it 
is?
- better still, since we are 100% certain that self is an objc object 
(or it wouldn't have been in an objc callback as self, right?) is there 
a way the bridge can be tweaked to skip checking on 'self' in all 
callbacks?
- alternatively is a lower-level high-performance slot accessor 
available that skips checking on any object that we're comfy with that 
can be substituted for the safe, slow one during optimization?

thanks,
h

On Aug 26, 2004, at 2:23 AM, Gary Byers wrote:

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