Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^2: String manipulation

by hotshot (Prior)
on Aug 01, 2004 at 13:57 UTC ( #379069=note: print w/ replies, xml ) Need Help??


in reply to Re: String manipulation
in thread String manipulation

My code is working, but what about effieciency and performance, is there a difference between the for loop in my suggestion to map?


Comment on Re^2: String manipulation
Re^3: String manipulation
by tachyon (Chancellor) on Aug 01, 2004 at 14:05 UTC

    My code is working

    Try and run it. It does not compile.

    My code is working

    Fix the compiler errors and then fix the logical errors so it produces what you say it should.

    My code is working

    Your code is most certainly not working. Just look at the loop and tell me how many loops you will get for $step = 1000 and numOfMembers = 1000. I get 1 loop, how about you? Don't see that adding 1000 members......

    for (my $i=2; $i<=$numOfMembers; $i+=$step) {

    cheers

    tachyon

      sorry, I pasted my code before fixing the iterator, should be $i++ instead of $i+=$step and missing '*' in the formula inside the for loop

        I figured as much but was in a bad mood, plus I miss Abigail and Abigail-IIs somewhat cuasic responses. Could have been that red too.

        cheers

        tachyon

Re^3: String manipulation
by Ovid (Cardinal) on Aug 01, 2004 at 15:18 UTC

    You'll find many nodes on the topic of performance optimization. Let me summarize all of them for you: don't optimize unless you need to.

    One of the biggest issues programmers face (myself included) is the tendency to say "this won't run fast so I had better speed it up." The reality is, if it runs fast enough, it runs fast enough. Particularly as a system gets large, it becomes more and more difficult to guess what will really speed things up. Even if you speed up a loop 100 times, if the program only spends one percent of its time there you've likely wasted your effort.

    But optimizing isn't really bad, is it? I mean, if I optimize everything won't my program will run really fast?

    The answer to that is a resounding NO! I can't recall offhand who said it, but one telling quote is "it's easier to optimize correct code than to correct optimized code." Every hoop you jump through to squeeze out every little bit of performance is another chance for your foot to catch on that hoop and make you stumble. You'll likely introduce more bugs and you'll simply waste time trying to second guess whether or not a particular construct can be faster when what you really want to be doing is delivering product. You'll also be more likely to obfuscate your code and make maintenance more difficult. Only when you have a deliverable and you can get an idea how it's likely to be used in a production environment can you really begin to start performance profiling to find out where the bottlenecks, if any, are.

    In summary, do not fall into the time-wasting trap of second guessing the performance of your code. Make your code correct and only when you really have a performance problem should you start profiling things. With a performance profile in hand, then you can know where you should be optimizing instead of guessing.

    (Note: the above is good general advice and there are definitely times it should be ignored, but once you get to the point where you can make the distinction you'll be giving others this advice :)

    Cheers,
    Ovid

    New address of my CGI Course.

      Wow, now's one of those rare times when I wish I could double-vote on a node.

      I'd say that optimization should be really, really rare. Correctness is *so* much more important that it really should get almost exclusive attention. If for example, you have a really horrifically borked query due to bad DB indexes, I'd suggest that you're facing brokenness not optimization at that point.

      Think *very* carefully before trading simplicity for performance.

        The funny things is, 9 times out of ten, simplifying your code is the best step you can take to optimising it--especially in perl.

        Of course, simplicity doesn't stop at the boundaries of the code you write. It crosses deep into all those "handy" modules kicking around.

        Dumb interface designs; over-designed, overly layered hierarchies; over reliance upon favoured methodologies, techniques and tools all conribute to complexity, and that usually translates to poor performance.

        Abstraction is good; design is everything--but knowing when to stop abstracting & designing is just as important.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail
        "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (12)
As of 2014-08-29 17:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (283 votes), past polls