From @jnthn

Given the following code​:

~~
sub ltp_1 {
  for (9...1) X (9...1) X (9...1) X (9...1) X (9...1) X (9,7,3) ->
$a,$b,$c,$d,$e,$f {
  }
}

sub ltp_2 {
  for 9...1 -> $a {
  for 9...1 -> $b {
  for 9...1 -> $c {
  for 9...1 -> $d {
  for 9...1 -> $e {
  for 9,7,3 -> $f {
  1
  }
  }
  }
  }
  }
  }
}

say now;
ltp_1;
say now;

say now;
ltp_2;
say now;
~~

The output is​:

Instant​:1347656155.562
Instant​:1347657301.502
Instant​:1347657301.508
Instant​:1347657351.156

That is, 146s vs. 50s (that's after an initial optimization to
infix​:<X>). Looking at the profile at C level, we spend a large amount
of time in perl6_rpa_find_type (a third of total execution time) in the
infix​:<X> case, and a further 27% of the time is spent doing
boolification (presumably the if statement in the implementation of
infix​:<X>).

Curiously, in the problem that showed this up​:

  http://rosettacode.org/wiki/Truncatable_primes#Perl_6

The difference was even more pronounced after switching to the for loop
approach.

  http://irclog.perlgeek.de/perl6/2012-09-14#i_5988681

For the record, it used to read​:

  for (9...1) X (9...1) X (9...1) X (9...1) X (9...1) X (9,7,3) ->
$a,$b,$c,$d,$e,$f {
  my @​x := [\+] $f, $e, $d, $c, $b, $a Z* (1,10,100 ... *);
  return @​x[*-1] if prime @​x[0] and prime @​x[1] and prime @​x[2] and
  prime @​x[3] and prime @​x[4] and prime @​x[5];
  }

Would be good to get to the bottom of why it's so much slower and see if
something can be done about it.

/jnthn

Functions

From @coke

Tagging [GLR] as hopefully this will be improved enough to close with moar/GLR.
--
Will "Coke" Coleda

From @niner

The example needed a little change after GLR​:
sub ltp_1 {
  for (9...1) X (9...1) X (9...1) X (9...1) X (9...1) X (9,7,3) -> ($a,$b,$c,$d,$e,$f) {
  }
}

With that the X version runs in 8.6 seconds on my machine while the nested for loop version takes 9.8 seconds.

The RT System itself - Status changed from 'new' to 'open'

@niner - Status changed from 'open' to 'resolved'