Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^4: Parsing named parameters

by robin (Chaplain)
on Nov 07, 2005 at 15:28 UTC ( #506378=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Parsing named parameters
in thread Parsing named parameters

What would be the penalty of performing the optimisation if you don't need it?

Why make something more complicated when it doesn't bring you any benefit? Some obvious disadvantages:

  1. You waste time writing more complicated code, with no benefit for your application;
  2. You make life harder for whoever has to maintain the code later (whether that’s you or someone else), again with no benefit;
  3. The optimised code, being more complicated, is more likely to have bugs;
  4. etc.


Comment on Re^4: Parsing named parameters
Re^5: Parsing named parameters
by BrowserUk (Pope) on Nov 07, 2005 at 15:30 UTC

    I was enquiring after the specific case of your example code, rather than the general case. How many of those still apply?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      How many of those still apply?

      All of them, I think. I suppose you could argue that (1) doesn't apply if you're copying and pasting the code from Perl Monks, but you still have to understand the code and adapt it to your precise requirements, both of which are more difficult when the code is more complicated.

      I'm bewildered by your objection, to be honest. Do you seriously think it's a good idea to optimise code that’s already fast enough? There’s an interesting debate to be had about “premature optimisation”, but I've never heard anyone advocate needless optimisation.

      Perhaps I'm missing your point. Would you care to elaborate?

        In the specific example you benchmarked, comparing the two versions side by side devoid of the benchmark code, with some unnecessary punctuation removed and a few extra spaces for clarity (this is not a criticism of your preferences!) you get this:

        sub { my %hash; my $reversed_data = reverse $data; $hash{ reverse $2 } = reverse $1 while $reversed_data =~ /\s*([^=]+?)\s*=\s*(\w+)/g; } sub { my %hash; my $data = $data; $hash{ $1 } = $2 while $data =~ s/\s*(\w+)\s*=\s*([^=]+)$//g; }

        The extra complexity amounts to 3 uses of the keyword reverse, and a longer variable name. The structure of the code is otherwise identical.

        My question really is, is that "extra complexity" so onerous as to amount to a maintenance problem?

        Conversely, whilst the original application's use of the subroutine in question may not greatly benefit from the optimisation, the next application that uses it could. It might call that sub in an inner loop and that 4.5x to 5x greater performance (on my machine) could be significant.

        More importantly, if the efficient version becomes the 'standard' way of implementing parsing named parameters, and is used universally, rather than alternating between the optimal and non-optimal versions on a case by case basis, then the optimal version will become 'normal' and what, if any, potential for a maintenance problem may exists as a result of the "extra complexity", disappears because of familiarity.

        I guess I am looking for the balance between consistancy in the face of future need, and simplicity.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Reaped: Please delete
by NodeReaper (Curate) on Nov 07, 2005 at 15:32 UTC
    This node was taken out by the NodeReaper on Mon Nov 7 16:36:01 2005 GMT
    Reason: [BrowserUk]: PLease delete--accidental duplicate

    For more information on this node visit: this

Reaped: Please delete.
by NodeReaper (Curate) on Nov 07, 2005 at 15:33 UTC
    This node was taken out by the NodeReaper on Mon Nov 7 16:49:50 2005 GMT
    Reason: [BrowserUk]: Please delete

    For more information on this node visit: this

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2014-12-28 23:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (183 votes), past polls