-- How??

Perhaps a better question would be "-- Why?" :)

As in: Why do you need to know this information?

The answers very much depend upon how you decide to construct your classes. And how you decide to construct your classes depends upon the choices you make. Some of those choices could be influenced by the design requirements of your classes.

Re: Making an Object faster? may shed a little light on some of the possibilities--though it is due for an update. Beyond that, it would possibly be more fruitful for you to post an outline of your requirements, you may then get better information regarding the trade-offs. And whatever implementation you use, there will always be trade-offs.

Some people critisise Perl's DIY object construction as too flexible, or too daunting, but remember that if Perl opted for a single mechanism, we programmers would be stuck with whatever choice was made. It may be that one choice could be made that would satisfy 80% or more of peoples needs, but the other 20% would be stuck with that decision. As it is, the programmer can make their selection of class implementation to satisfy it's specific requirements, even if this means trading (say) less imposed "security" for a lighter foot-print and faster exectution. Conversely, in those environments where security is paramount, you can go the other way and accept slower performance in favour of having a shotgun on the door to keep ouut intruders.

We'd all like it if there was a single mechanism that ran so fast we could measure it; used no memory; trapped all attempts to subvert the defined interface; allowed for single-, multi- and trait-style inheritance; but you'd still be making trade-off somewhere.