Just another Perl shrine | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
As I noted, C is the language for the job. It doesn't really matter how efficient the regex solution, C can work on the data in-place without incurring much in the way of dynamic allocation costs. You have mitigated this disadvantage to an extent in your version by placing certain limitations on the algorithm, notably the 500 unit capture max. This changes the situation considerably. However the design you chose isn't competitive unfortunately :/ primarily I suspect because its not an optimised line within the re engine to be used like this, although that is conjecture sicne i'm not familiar with the internals.
Length: 1920 Enlil 2: 0.93203s Dingus 1: 0.530455s Dingus 2: 0.537765s Rasta 1: 1.973259s TommyW 1: 0.87257s Robartes 1: 0.996671s PhiRatE: 0.232084s BrowserUk: 2.764623s edit: note that this is for 100 iterations With the code done like this:
I anticipated that perhaps the startup cost of the regex generation might be causing the performance problem, so I ran a 1000 unit test as well, against only my entry.
Length: 1920 PhiRatE: 2.241276s BrowserUk: 28.384692s Note that you got similar results, I'm running 100-1000 runs of the same line, you only did one :) My recommendation is either go with the Inline C one if you really need the speed, or Dingus' 2nd variant, which is the cleanest, closest perl variant. In reply to Re: Re: Re: Re: Efficient run determination.
by PhiRatE
|
|