in reply to Re: Re: Micro optimisations can pay off, and needn't be a maintenance problem
in thread Micro optimisations can pay off, and needn't be a maintenance problem

Hmm, I think I would prefer to keep it all in one file, perhaps putting the "original" in a =tobespeeded/=cut section.

But, I like the idea. You are basically inlining the functions that the compiler can't.

However, it also loses any polymorphism. That is, it becomes non-virtual.

  • Comment on Re: Re: Re: Micro optimisations can pay off, and needn't be a maintenance problem

Replies are listed 'Best First'.
Re: Re: Re: Re: Micro optimisations can pay off, and needn't be a maintenance problem
by mirod (Canon) on Nov 13, 2002 at 17:50 UTC

    Yes, it looses polymorphism, or at least it prevents a subclass to replace those methods. The main advantage is that I can keep the code rather clean and OO, while getting the speed bonus of not having methods internally (about a 30% gain in my tests). And if in the future I want to change the implementation I can, I just have to remember to remove the field from the list. An alternative suggested by tilly was to just use the hash and to switch to a tied hash when needed (Re (tilly) 1: Speeding-up OO accessor methods).

    BTW I looked into doing real inlining (including with the pre-processor) but did not find a way at the time (4 years ago). It might be feasable now, with a source filter. Now that would be a useful module!