For me, it'd depend on several factors.

  1. How critical would speed be in this module? Would it just be something that's nice to have, or would it be crucial to the module's operation? They say that optimization should always start with profiling: figure out where you actually spend time. Same thing here; would the module likely be a bottleneck in an application using it?

  2. In the same vein: how much of an absolute slowdown would there be? "The module runs twice as slow as before with this feature added" sounds bad, but if we'd be talking about an increase in running time from (say) 1ms to 2ms in code that'd only be used once in an app, that'd be much less of an issue than a larger (absolute) slowdown, or a slowdown in code that is expected to be called in a tight loop.

  3. I'd also consider what the module is actually doing. To give just one example, graphical UIs need to be snappy to feel natural and usable, so I'd be wary of introducing delays in UI code without a good reason; but other tasks are understood and expected to take some time (though that doesn't mean it's always proper make them take more time, even in exchange for extra features).

  4. Then of course there's the question of whether said new feature would need to cause a slowdown at all. Perhaps there'd be an alternate implementation that would run faster. It might be less elegant perhaps, less natural, longer and more complicated -- but why care how sausages are made when you only want to eat them?

  5. If neither decision could be justified at all, I might simply split the module into two versions: a fast, lean one that provides only the necessary features and squeezes out the last bits of speed, and a full-featured one that makes a few sacrifices for the sake of convenience.

TL;DR: like so many things in life, it depends.

In reply to Re: Speeds vs functionality by AppleFritter
in thread Speeds vs functionality by Tux

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.