Functions have a lot of CPU overhead, so store data where you can, and use direct access for that data.

This is entirely too simplistic a view.

Optimization is often about making a trade-off between space and time. Which way to go depends on the characteristics of your (working) application. To prejudge what you'll need optimize and how is a grand mistake. Unless you have a lot of experience. Then, it's merely a mistake.

If you're running up against the edge of your available memory, pushing stuff into memory risks causing virtual memory thrashing, which can be enormously expensive.

Here's an example from your earlier Possible Memory Usage Issues post: You're representing a Tree in memory. You have Node and Leaf objects. During a tree traversal, you need to distinguish between (internal) Nodes and Leafs. How do you do this?

One way to to store a type indicator in each object, and to either provide an common accessor for this field, or allow clients to peek into the object directly, so that the type can be queried. Let's assume you're doing pedal-to-the-metal optimization, and have made the dubious choice* to let clients peek into the objects directly. This approach trades away time for space (the extra slot in each object. Each time you create a Node or a Leaf, you're taking on the (slight) extra overhead of setting up an additional slot or association, and each object carries around the extra space.

Another approach is to dispense with a common type field in favor of a predicate function, which might be implemented as follows: 

  package Node;
  ...
  sub isLeaf { 0 }
  ...
  package Leaf;
  ...
  sub isLeaf { 1 }

[download]
This approach trades away space for time. Because of method lookup, it's a bit more expensive to do   if ( $o->isLeaf() ) { ... than it is to do   if ( $o->[$Node::isLeaf] ) { ... but which is better?

And the answer is: It Depends!

And this is only a simple example. There are a range of space-for-time tradeoffs possible in many applications, including caching (or not caching) frequently calculating intermediate results.

Unless you measure a working application on real data, you won't know for sure. To paraphrase Sherlock Holmes, "It is a capital crime to optimize before one has collected data."


*Allowing clients to peek directly into objects increases "coupling", which makes an application harder to maintain and modify. Much of the flexibily of objects is that they hide their internal representation from clients, allowing implementations to be easily replaced.

In reply to Re: Faster Perl, Good and Bad News by dws
in thread Faster Perl, Good and Bad News by abitkin

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.