You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code for all constructor patterns suffers from two inefficiencies. First, there is an unnecessary null-check (note that isInstanceOf will succeed only if scrutinee is non-null). Second, unused fields are still copied into local variables, even if the variable is a wildcard.
Consider this program
objectTest {
deffoo(xs: List[Int]) = xs match {
case x :: _ => x
}
defbar(xs: List[Int]) = xs match {
casexs: ::[Int] => xs.head
}
}
The two methods should produce equally efficient code. Yet foo takes 48 bytes where bar only takes 34. I have not measured the performance impact of the additional 14 bytes. But in any case 34 vs 48 means that bar can be inlined whereas foo cannot.
I have fixes in the pipeline so that both methods are 28 bytes long
under -optimize (exactly the same)
without -optimize, foo is 38 bytes and bar is 34 bytes long,
essentially due to the conflicting requirements of #5158 (store subpatterns in local variables to improve debuggability)
As soon as I have the tests implemented (using Greg's new bytecode testing framework), I'll submit a PR.
The code for all constructor patterns suffers from two inefficiencies. First, there is an unnecessary null-check (note that isInstanceOf will succeed only if scrutinee is non-null). Second, unused fields are still copied into local variables, even if the variable is a wildcard.
Consider this program
The two methods should produce equally efficient code. Yet foo takes 48 bytes where bar only takes 34. I have not measured the performance impact of the additional 14 bytes. But in any case 34 vs 48 means that bar can be inlined whereas foo cannot.
Here's the javap output I am seeing:
The text was updated successfully, but these errors were encountered: