Re (tilly) 2: Benchmarks: Costs of OO Perl

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.

Comment on Re (tilly) 2: Benchmarks: Costs of OO Perl

Replies are listed 'Best First'.
Re: Re (tilly) 2: Benchmarks: Costs of OO Perl by coreolyn (Parson) on Jan 11, 2001 at 03:57 UTC
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]
Re (tilly) 4: Benchmarks: Costs of OO Perl by tilly (Archbishop) on Jan 11, 2001 at 05:20 UTC
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]