"...it is too slow"

Yes, it may be, particularly since it's only pseudocode. So I'd be more confident about ruleing out such an approach if I knew "how did you test it?" You may be -- even probably are -- right, but I'm not buying that until I see how you translated the pseudocode into compilable code... and what your benchmarks look like.

Somewhat similarly, your statement that ack is " is slower than the "pure perl" implementation when using anchors or \b,\s etc " is hard to credit. I see your timing code in "sub6," but not the quantified results, nor any test results on the system (external) ack (see JavaFan's Re^3: push to an array lines matching a pattern, and the lines before and after the matching0 or grep. It's all to easy to implement timings in a manner that gives misleading results.

And as to " chang(ing) the number of rows captured," that requires additional buffers (or, if you're slurping the entire file into an array, an index of array elements you've checked.) The extra buffers, and moving the data thru them would certainly slow the process... but again, I'd like to see a benchmark. OTOH, that may be better solved by tweaking LanX's observation about using seek in a sliding window.

sorry, I updated only the first post with the correct timings
ack from the command line, takes 15 seconds
this code, simpler than your pseudo code, takes 10 seconds


use 5.014;
use warnings;
use Time::HiRes qw(usleep ualarm gettimeofday tv_interval);

my @array;
my $pattern = '\bsala|che|relazione|di|questo|coso|^qui\$';
open( my $filehandle, "<textMatchInAfile.txt" );
my $time = [gettimeofday];
while (<$filehandle>) {
    if ( $_ =~ /$pattern/ ) {
        push @array;
    }
}
say 'time while' . tv_interval($time);
[download]