Re^3: Hash space/ time tradeoff

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

Comment on Re^3: Hash space/ time tradeoff

Replies are listed 'Best First'.
Re^4: Hash space/ time tradeoff by educated_foo (Vicar) on Dec 28, 2013 at 05:49 UTC
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.	[reply]
Re^5: Hash space/ time tradeoff by GrandFather (Saint) on Dec 28, 2013 at 08:41 UTC
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	[reply]


Just another Perl shrine
	PerlMonks