This issue was discussed before here, but I still think that I don't
have a sufficiently clear picture about it.
I recall reading that specializing SLOT-VALUE-USING-CLASS is likely to
incur a serious performance penalty for all classes in a system, because
they at least have to check whether the specialization applies or not.
For example, Kenny has reported a 30% slowdown in experiments he has made.
Several questions here:
- Is this really the case? I don't have a sufficiently large program to
benchmark this, but I am a little bit worried about it. On the other
hand, this might just be another example of "don't worry until it really
hurts you, and then it's probably straightforward to fix the
bottleneck". Can anyone confirm this? What are your experiences?
- If that's really the case, my current take would be to divide slot
access into the two categories "accessor methods" and "direct slot
access". For accessor methods, I would implement the "correct" behavior
for a given metaclass - for example accessing the slot in a hash table
or a data base. For direct slot accesses via slot-value, I would leave
them as is, making them something like a way to access "system slots"
beneath accessor methods. So for example, in this way I could access the
reference to a hash table or the details of the database that is
accessed. This seems to be in line with at least some of the examples I
have seen, for example in Andreas Paepcke's book. (BTW, an excellent
book that!)
On the other hand, I have seen other examples, in which care was taken
to have both accessor methods and direct slot accesses implement the
"correct" behavior.
Would you agree that the separation of accessor methods and slot
accesses is a good idea, or are there problems that I would buy into
which I am currently missing?
Thanks for replies in advance,
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> I recall reading that specializing SLOT-VALUE-USING-CLASS is likely
> to incur a serious performance penalty for all classes in a system,
> because they at least have to check whether the specialization
> applies or not. For example, Kenny has reported a 30% slowdown in
> experiments he has made.
>
> Several questions here:
>
> - Is this really the case? [..]
I would expect any performance-tuned CLOS implementation to recognize
at compute-applicable-methods-time for some standard-accessor-method
whether the SVUC involved is the standard one or if it is specialized,
and if the former is the case, cache some effective method that
shortcuts the normal slot-access protocol. (This caching will not
apply to calls to slot-value, however, but I suppose similar
techniques could be applied for systems that do inlining of
slot-value.)
Of course, this cache will then have to be invalidated whenever new
methods are added to/removed from SVUC, so if this was to happen
frequently, there will be some overhead. But this shouldn't come as a
surprise to anyone.
--
Frode Vatvedt Fjeld
On 2004-01-27, Pascal Costanza <········@web.de> wrote:
> I recall reading that specializing SLOT-VALUE-USING-CLASS is likely to
> incur a serious performance penalty for all classes in a system, because
> they at least have to check whether the specialization applies or not.
> For example, Kenny has reported a 30% slowdown in experiments he has made.
>
> Several questions here:
>
> - Is this really the case? I don't have a sufficiently large program
> [...]
I've benchmarked AllegroCL to be up to 100% slower using Hyperobject
(http://hyperobject.b9.com) with slot-value-using-class. Hyperobject
can use SVUC for rules checking the values supplied to slot writer
methods. In the current Hyperobject source, I have a reader
conditional to that SVUC is not defined in applications which don't
use writer value verification.
In my benchmarking other CL implementations, however, I don't recall
serious performance penalties using SVUC.
--
Kevin Rosenberg
·····@rosenberg.net
Kevin M. Rosenberg wrote:
> In my benchmarking other CL implementations, however, I don't recall
> serious performance penalties using SVUC.
Thanks to you and Frode for responses. Sounds good!
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."