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

Re^2: Display shortened paragraph

by blazar (Canon)
on Feb 01, 2006 at 12:06 UTC ( [id://527037]=note: print w/replies, xml ) Need Help??


in reply to Re: Display shortened paragraph
in thread Display shortened paragraph

<rant>
While it is interesting to note that duff's solution is reasonably fast (compared to the other ones) even if it does a more complex task, and definitely a more appropriate one to the needs of the OP, let's please try not to go mad about doing Benchmarks for every single thing that is posted here. This may convey the impression that premature optimization does matter, while it doesn't. By any means. In particular in this case as soon as I have some code that works, I would rather "rate" it based on readability or perhaps adaptability but for heaven's sake: not on speed!
</rant>

Replies are listed 'Best First'.
Re^3: Display shortened paragraph
by GrandFather (Saint) on Feb 01, 2006 at 18:19 UTC

    I agree that premature optimization is an evil thing. Having some knowledge about the relative merits of different approaches to solving a problem is an essential part of providing a good solution. Execution efficiency is one parameter that should be considered when evaluating different approaches.

    That is not to say that you should "benchmark early and often". In fact, generally you don't need to benchmark at all in the normal course of writing code (in any language). However at PerlMonks we are in a special situation where all facits of a piece of code come under scrutiny for the edification of the monks.

    I say, in the context of PerlMonks, where many different approaches to solving a problem are suggested, that benchmarking should be done "early and often". In this particular case there are in essence three different approaches suggested with wildly different execution speeds. The benchmark should strongly convey that dealing retail with characters is SLOW (jbrug2) and that narrow purpose functions (substr, rindex) are faster than general purpose functions (regex). That is a valuable lesson in any book!


    DWIM is Perl's answer to Gödel
      The benchmark should strongly convey that dealing retail with characters is SLOW (jbrug2) and that narrow purpose functions (substr, rindex) are faster than general purpose functions (regex). That is a valuable lesson in any book!

      (Forgive me for the sarcasm but...) Whoa! I would have never expected, without running a benchmark!!

      In particular jbrug2 is

      sub jbrug2 { my @a = split("",$str); my $txt = ''; for (my $i=0; $i<$maxlen; $i++) { $txt .= $a[$i]; } }

      Be sincere: do you really need a benchmark to have an idea of the performance merits of code that basically does a perl reimplementation of substr by using a C-style for loop to append entries of an array to a variable one at a time?

      Whatever, what I'm contending is that while a valuation of relative merits in terms of performance may have some relevance in other cases, it has none for this task. The OP is asking for a method to display some text a chunk at a time, to ease reading. What is the point of searching for the maximum speed of execution when any solution, including jbrug2, is well beyond the limits of human perception?

      Personally I think that there are (by far) more important/interesting aspects to take care of. For example your benchmark compares some approaches to take (about) the first 255 charachters of a string. How do they scale if the requirement is added to take successive chunks? What if the string is less than 255 charachters? These are points to be discussed. But your post claims "and the best answer is: [benchmark]"

      FWIW add this beautiful creation of mine to the benchmark, if you like:

      sub blazar { local $_=reverse $str; my ($cnt,$txt)=$maxlen; $txt.=chop while $cnt--; }

        My Re^3: Display shortened paragraph reply was intended to discuss the common use of benchmarks at PerlMonks and why a benchmark is a useful tool for illustrating why some coding decisions are made. I'm sorry I didn't make that sufficiently clear to you.

        I agree that in the strict context of UI computational efficiency in most cases doesn't matter at all. However the real lesson from the benchmark is that specific purpose built in functions perform better than general purpose functions - and that knowledge can be applied all over.

        To someone who has been kicking around the Perl world for a while and already knows everything there is to know about Perl of course the result of any benchmark comes as no surprise. That is not true for everyone here, and particuarly it it not true for many of the people who ask for help here and those who read through the replies looking for interesting knowledge. Well constructed benchmarks are a valuable resource here, and often the discussion pertaining to how to construct a particular benchmark is valuable too. This sort of, peripheral to the main question, discussion often provides the most useful insight and understanding.

        Personally I think that those who know of (by far) more important/interesting aspects should contribute the results of their own research and knowledge.

        But your post claims "and the best answer is: benchmark"

        Yes, that did need a tongue in cheek smiley didn't it :-)


        DWIM is Perl's answer to Gödel

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2024-04-19 21:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found