This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GNU ObjC runtime class table rewritten



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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]