Performance regression with loop() in a class sub

[MasterDuke17]

This code:

class FOO {
	our proto sub foo($) {*};
	multi sub foo(Int $n) {
		my @a = ^$n;
		my $b;
		loop (my $i = 0; $i < $n; $i++) {
			$b = @a[$i]
		}
		$b
	}
	multi sub foo(Str $s) {
		foo($s.Int)
	}
}

say FOO::foo(1_000_000);
say now - INIT now

used to take ~1.3s, but after 48ce47e takes ~2.1s. This was discovered when benchmarking some changes to String::CRC32. The sample code use String::CRC32; say String::CRC32::crc32("abcdefghijklmnopqrstuvwxyz0123456789~!#^_+;:./>?" x 100_000), using cosimo/perl6-string-crc32#12, caused 4.8 million calls each to MVM_frame_find_lexical_by_name for &postfix:<++> and &infix:«<».

[MasterDuke17]

https://gist.github.com/Whateverable/7e08b6856f9aa8c20358e7370961d1cb has the timings for releases.

[MasterDuke17]

https://gist.github.com/MasterDuke17/ece191957c1ee47136650926da661c75 has the output of MVM_dump_bytecode(tc) at the top of MVM_frame_find_lexical_by_name when name is '&postfix:<++>'.

[jnthn]

It seems it produces nicely optimized code...but then never manages to complete OSR and use it.

[jnthn]

It's still not clear how this ever worked (and it might have done so accidentally...) but the problem is that a proto invokes the body with invokewithcapture, and OSR doesn't know how to find the args and callsite for doing an arg guard test.

[MasterDuke17]

Think this is something I could fix with a pointer to where OSR is failing?

…

Sent from my iPhone

On Mar 25, 2020, at 11:33 AM, Jonathan Worthington ***@***.***> wrote:  It's still not clear how this ever worked (and it might have done so accidentally...) but the problem is that a proto invokes the body with invokewithcapture, and OSR doesn't know how to find the args and callsite for doing an arg guard test. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jnthn]

I already have a patch that helps (the time it outputs goes from 3.76 to 0.70 on my slow home VM); just been checking it doesn't knock off OSR otherwise (seems not) and spectesting it.

[jnthn]

Fixed with MoarVM/MoarVM@f2a52cf5d7.