Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re^2: Hash space/ time tradeoff

by educated_foo (Vicar)
on Dec 28, 2013 at 01:45 UTC ( #1068572=note: print w/replies, xml ) Need Help??

in reply to Re: Hash space/ time tradeoff
in thread Hash space/ time tradeoff

After all, if it ain't broke, don't fix it. On the other hand, a stitch in time saves nine. On the third hand, a penny saved is a penny earned. Or maybe that was the fourth hand.

The OP has his reasons for asking the question, and as some other commenters have shown, it's a good jumping-off point for discussion of how to reason about different collections of data indexed in different ways. Given that the OP could have written both approaches, benchmarked them, and chosen whichever came out best in about 10 minutes, I don't see "a lot of time" being "wasted."

Replies are listed 'Best First'.
Re^3: Hash space/ time tradeoff
by GrandFather (Saint) on Dec 28, 2013 at 04:09 UTC
    Given that the OP could have written both approaches, benchmarked them, and chosen whichever came out best in about 10 minutes ...

    Actually it's likely that the OP couldn't do that. He spent more time than that writing up the question then waited most of an hour for the first answer. So it looks like a 10 minute fix wasn't available and there's the first hour wasted.

    But the advice doesn't pertain to just this single question or to just the OP. As a general thing write code for clarity first then tweak for speed if you need to. Most often scripts are plenty fast enough as first written. If they're not fast enough then profiling is a better first step than guessing and benchmarking. Often the answer to speed problems is found in a different high level approach than low level tweaking in any case. Tweaking may get a factor of two speed improvement. Finding a better algorithm can get orders of magnitude speed improvements.

    So, pick your battles and don't sweat the small stuff.

    True laziness is hard work
      So, pick your battles and don't sweat the small stuff.
      For want of a nail...

      You write some garbage that's "fast enough" for you, then the next guy writes some garbage on top of yours that's "fast enough" to collect his paycheck, etc. Eventually some poor schlub has a program that runs forever, benchmarks it to find a flat profile, tries to fix your stuff, and finds layer on layer of "good enough" design.

      If you think a bit and write something decent, other people will be able to reuse your code. However, if you generate garbage, some poor fool will just have to rewrite it later. "Whatever you thought of first" and "whatever seems clear to you" are not necessarily decent.

        I agree - think a bit and write something decent, but in the words of Scotty: "The more they overthink the plumbing, the easier it is to stop up the drain".

        You are conflating good overall design with sweating the small stuff. If the overall design is good then the problematic bottle neck code can easily be identified by the schlub and fixed in isolation from the rest of the code, especially if there is a good suite of unit tests for the code.

        Any army that puts itself in a position of depending on a single nail for success is doomed to failure. Bending an initial design to anticipate future problems most likely wastes time now and probably doesn't help with the unforeseen problems that actually arise in the future. Anticipating a missing nail or any other single detail is hard and time consuming. Ensuring there are sufficient blacksmiths available is easier, prevents the issue and allows a better design of nail to be adopted in the future if required.

        True laziness is hard work

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1068572]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (3)
As of 2021-10-25 22:19 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (90 votes). Check out past polls.