Re^4: substr question

[ikegami]

but a suggestion that a regex approach might make sense.

That had already been done.

this will work better, certainly.

That's a lot of code. Does it do anything different than the following?

print $string =~ /^(.{0,100})(?!\S)/;

[stevenmay]

Well, I generally prefer to break things into more verbose code to make life easier 2 years down the road (or next week) when I have to change something.

Too, experience said my approach should be faster since more but easier (for Perl) regexes are typically faster than one complex one.

Just out of curiosity I ran a test and Benchmark confirmed my suspicion.

I set up the test with each sub populating $string from a global, processing it and returning the results. With 10,000,000 iterations it's around 8.75 seconds for the one liner, and around 4.75 for my multi-line example on my machine.

I fiddled the code a bit to see if minor variations made any difference with little change in the times in either approach.

So, a little less than twice as fast in execution time...

Not a big deal at all with any reasonable number of string matches, but a little here, a little there...

Anyway, the OP was presented with several options. Life is good.

\s

[ikegami]

I generally prefer to break things into more verbose code to make life easier 2 years down the road (or next week)

How is trying to understand 50 instructions easier than understanding 5. Your code is so complex it would take quite some time for me to understand it now, in weeks, in years.

experience said my approach should be faster since more but easier (for Perl) regexes are typically faster than one complex one.

Both of your regex are more complex than mine. (All three read linearly, but yours are longer.) Plus you have numerous additional Perl ops. It makes no sense for your code to be faster when the regex are executed. And it's not. You probably didn't take into account that your solution modifies the input.

('x' x 90).' '.('x' x 10)
  
              Rate stevenmay  ikegami2  ikegami1
stevenmay 256955/s        --      -35%      -48%
ikegami2  394568/s       54%        --      -19%
ikegami1  490119/s       91%       24%        --


('x' x 10).' '.('x' x 90)

              Rate stevenmay  ikegami2  ikegami1
stevenmay 102399/s        --      -13%      -19%
ikegami2  118154/s       15%        --       -7%
ikegami1  126866/s       24%        7%        --

In the case where the string is shorter than 100, having the check makes it faster. You can always add that to mine. That's what ikegami2 is.

('x' x 99)

               Rate  ikegami1 stevenmay  ikegami2
ikegami1   771011/s        --      -81%      -83%
stevenmay 4071762/s      428%        --      -12%
ikegami2  4620312/s      499%       13%        --

Benchmark code:

Read more... (1229 Bytes)

[stevenmay]

'Your code is so complex it would take quite some time for me to understand it '

Certainly it depends on what a person is used to. Let's agree we approach things differently at this point.

Note that I *am* concerned about generating code that is opaque to others, and am taking your comment seriously.

The interesting bit is your benchmark results.... I went back to look at the benchmark I ran last night.

Oops.

Typo.

I stand corrected, my code is slower.
I'd set up a test string that was less than 100 characters. So the extra ops were not even looked at and once that was corrected, my code was approximately 3 times slower. Darn.

I do thank you for the time you've spent on me. While you might think it wasted, I certainly do not.

\s