in reply to Benchmarks: Costs of OO Perl
in thread Dice::Die

I didn't scan all your article, but if you realize that most of the work of an object is not during dispatch, then your "20%" will become more like "2%" for non-trivial objects. I remember Damian saying this at a talk he gave last summer, and I think he'd know, having written the book on Perl Objects.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
Re (tilly) 2: Benchmarks: Costs of OO Perl
by tilly (Archbishop) on Jan 10, 2001 at 06:14 UTC
    Whether or not most of the work of an object is during dispatch depends on how your have designed your system. In the example that led coreolyn to do those benchmarks the majority of the work actually was in creation of objects and dispatch to them. In a sample run I doubled the performance by doing direct hash access to attributes of objects rather than calling get methods.

    But yes, I think it is generally true that experienced OO programmers come up with designs where dispatch is not a major bottleneck.

[reply]

      You may notice that the latest version makes use of the direct access. Is is Politically correct to access attributes directly if you are in that class? Is there a downside? I understand the hazards of direct access outside of a class but haven't considered internal direct access.

      coreolyn
[reply]
        As far as I am concerned it is not only correct, it is advisable.

        The principle of encapsulation is that you want to localize assumptions about the internal implementation into one section with a well-defined and simple interface to the outside world. The point of that is so that you can change the implementation if you need to. (Part and parcel of this is that you don't expose any piece of functionality in your interface until you need it. After all the richer your interface, the harder it is to change the implementation.)

        That does not mean that you intentionally choose an implementation you are likely to want to change. Given the fact that get/set methods are so much slower than direct access of attributes, unless you need the extra flexibility from the start of being able to override the implementation in subclasses, by default start with an implementation that is fast.

        Another way to put it is design your program so that you can change your implementation at will (and make a practice of doing proactive tweaks from time to time just to keep you aware of things that you do which make those changes hard) but also try to find implementations that you don't think you will want to change...

[reply]

In Section Code Catacombs