Rate jbrug2   duff  jbrug  graff
jbrug2    3596/s     --   -98%   -99%  -100%
duff    153325/s  4164%     --   -78%   -94%
jbrug   689852/s 19086%   350%     --   -73%
graff  2525239/s 70130%  1547%   266%     --
[download]

<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>

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];
    }
}
[download]

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--;
}
[download]