This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GNU ObjC runtime class table rewritten
- To: Ovidiu Predescu <ovidiu at cup dot hp dot com>
- Subject: Re: GNU ObjC runtime class table rewritten
- From: Nicola Pero <nicola at brainstorm dot co dot uk>
- Date: Fri, 1 Jun 2001 11:07:57 +0100 (BST)
- cc: Stan Shebs <shebs at apple dot com>, gcc-patches at gcc dot gnu dot org
Hi Ovidiu, sorry for answering for the third time - the fact is I enjoy a
lot discussing this stuff :-) - and I think my answer of yesterday night
was a bit too vague.
> However this will not help much during searches, so
> probably a better idea is to insert the node in the linked list so
> that it is sorted based on the length of the class name. You can than
> modify the class_table_get_safe() function to take into account this
> modification.
Hmm - I could make this change in a couple of minutes - now, should I or
should I not. I tend to prefer to avoid it because the simpler the code,
the better - this change is meant to make faster the case when the class
is *not* found in the table, isn't it. That should be an exceptional
condition during messaging, either generating a runtime error, or
triggering loading of the class from somewhere else (such as a bundle) -
both cases are sort-of once-in-an-app-lifetime events, speed is not that
critical and the improvement would be just a couple of C integer
comparisons and pointer reading (for a huge number of classes; nearly no
improvement for normal apps).
I prefer to purge away all little optimizations which do not make a real
difference so as to make the code easier to grasp.
Anyway, if you really think it's better to make it, I'll implement it.
> Maybe a smarter arrangement of the linked list could also be
> done. Moving the node corresponding to a class to the beginning of the
> linked list, based on the access frequency may help in cases where the
> program has a large number of classes. However the bookkeeping may be
> too costly to be done on each class lookup.
Yep - not a feasible solution - bookkeeping is going to be too costly.
> Probably a better approach is to modify the size of the hash table
> dynamically, as the number of classes in the program increases.
Hm - that would be quite more difficult than the current solution. If you
resize the table and copy the entries, you then have the problem of
releasing the old table - which is difficult because without locks, it's
difficult to make sure all readers have finished reading the old table - I
prefer to avoid this problem if we can avoid it.