Re^2: foreach argument modification inside loop, followed by return from loop

[vsespb]

Maybe. Have you tested this with every significant code path in the Perl interpreter on multiple platforms?

that's what I actually ask in my question.

What's wrong with print grep { $_ != 3 } @a;, anyway?

that was just proof-of-concept code

[rjt]

that was just proof-of-concept code

Understood, and thanks for posting your real code farther down the thread. Based on that, the relevant logic you have is this:

my $idx = 0;
for my $j (@a) {
    if ($j == $target) {
        splice(@a, $idx, 1);
        last;
    }
    ++$idx;
}

Which helps clarify what you're trying to do: remove an element from an array by value. I'm still far from convinced that there is any benefit to a splice/last approach, even based solely on the grounds that it's slower and more complex than something like this:

my $idx = firstidx { $_ == $target } @a;
splice(@a, $idx, 1) if $idx >= 0;

Timing for 1e6 entries:

           Rate      for firstidx
for      24.3/s       --     -22%
firstidx 31.1/s      28%       --

Certainly in this case, the for approach seems clearly suboptimal (List::MoreUtils' XS code does essentially the same thing as the for loop, much faster and more cleanly). Results were similar with any array sizes where efficiency is likely to matter.

Read more... (1267 Bytes)

[vsespb]

I'm still far from convinced that there is any benefit to a splice/last approach, even based solely on the grounds that it's slower and more complex than something like this:

I agree. This can be optimized-out.
Problem that I mentioned in my posting Re^2: foreach argument modification inside loop, followed by return from loop that "for" loop is in get_task(). i.e. there is another outer "for" loop.

[rjt]

I see that, however from what I can see that whole file could be easily refactored to not only avoid deleting within the (outer) for loop, but be significantly more concise as well. Here's a grossly oversimplified version of your code logic (at least the parts pertinent to this discussion):

OUTER: for (1) {
    for my $job (@jobs) {
        my ($status, $task) = $job->{job}->get_task();
        if ($status eq 'wait') {
            if ($self->{one_by_one}) {
                return 'wait';
            } else {
                return 'wait' unless --$maxcnt;
            }
        }
        elsif ($status eq 'done') {
            ($s, $t) = do_finish($job); # do_finish deletes from @jobs
            redo OUTER if $s eq 'ok';
            return ($s,$t); # (else)
        } else {
            my $newtask = Package->new(...);
            return ($status, $newtask);
        }
    }
}
return('wait')

You might already get away with the do_finish call, since you either redo outside the for, or exit the sub, but it might not stay that way if your logic changes in the future (it does create a bit of a trap for the unwary).

As far as I can tell, you only ever look at the first element of the jobs array; all cases eventually lead to a return or redo OUTER, right? If that's the case, you don't need to loop through the jobs at all. And, one more optimization: by extension of the last point, you only ever call do_finish on that first job (in the get_task loop context), right? So you don't need splice at all, just shift.

NEXT:
my $job = shift @jobs;
my ($status, $task) = $job->{job}->get_task;
return 'wait' if $status eq 'wait'; # All 'wait' roads went there.
if ($status eq 'done') {
    my ($done_s, $done_t) = $self->do_finish($job);
    goto NEXT if $done_s eq 'ok';
    return ($done_s, $done_t);
}
my $newtask = Package->new(...);
return ($status, $newtask);

I haven't had much time with your code at all, so it's quite possible I missed something (or there are planned additions that would invalidate my approach). Just remember my main goal was to get you thinking about one way you might start to rework the outer code for easier human comprehension, conciseness, not to mention getting rid of any need to flirt with array modification inside a loop.

And this is just one of many ways. Let me/us know which way you end up going, or if you'd like more input.