Re^3: quickness is not so obvious

How do you justify spending even five minutes thinking about how to improve the algorithm when you can solve the issue in 30 seconds and two lines of code? Of course after you've sent 30 seconds and found that the problem isn't solved, then it's time to think about smarter ways to approach the problem.

I know where you are coming from. Tricks like Memoize feel like cheating. But if it gets the job done and keeps getting it done then it's probably the right solution.

Perl is the programming world's equivalent of English

Comment on Re^3: quickness is not so obvious

Replies are listed 'Best First'.
Re^4: quickness is not so obvious by SimonPratt (Friar) on Jan 26, 2015 at 10:57 UTC
Its not so much that it feels like cheating, its more the impact of a module like `Memoize` might have on the underlying system that concerns me. It is entirely possible for an inexperienced developer to build a program that runs entirely fine on their test system, however on a production system is far too memory hungry and causes more problems than it solves. Yes, I am aware that `Memoize` gives you options to limit the memory footprint, however that then trades off against the performance boost (and quite possibly entirely negates it) So yes, in my job where I regularly deal with data sets that can easily fry servers with over 100GB of RAM, I can and do justify spending time finding the most efficient algorithm I possibly can and avoid using memory hungry workarounds such as `Memoize`. Then again, we spend a lot of time doing research for every aspect of our systems, as the more efficient and faster they are, the more productive (and therefore more valuable) they are. At the end of the day though, everyones environment is different and likewise the development focus and priorities are different.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: quickness is not so obvious
by SimonPratt (Friar) on Jan 26, 2015 at 10:57 UTC

Its not so much that it feels like cheating, its more the impact of a module like Memoize might have on the underlying system that concerns me. It is entirely possible for an inexperienced developer to build a program that runs entirely fine on their test system, however on a production system is far too memory hungry and causes more problems than it solves.

Yes, I am aware that Memoize gives you options to limit the memory footprint, however that then trades off against the performance boost (and quite possibly entirely negates it)

So yes, in my job where I regularly deal with data sets that can easily fry servers with over 100GB of RAM, I can and do justify spending time finding the most efficient algorithm I possibly can and avoid using memory hungry workarounds such as Memoize. Then again, we spend a lot of time doing research for every aspect of our systems, as the more efficient and faster they are, the more productive (and therefore more valuable) they are.

At the end of the day though, everyones environment is different and likewise the development focus and priorities are different.

[reply]
[d/l]
[select]