Interesting. Would you mind sharing your numbers for each alternative you tried?
In theory, null checks are free, but there is the added bytecode size. See:
"Null checks are cheap. They usually fold straight into a related memory access instruction, and use the CPU bus logic to catch nulls. (Deoptimization follows, with regenerated code containing an explicit check.)
User-written null checks are in most cases functionally identical to those inserted by the JVM.
Null checks can be hoisted manually, and suppress implicit null checks in dominated blocks."
Yes, increased code size is the problem. The heuristics built into scalac's inliner are very sensitive to them, preventing inlinings currently done. The non-redundant null-checks, once in place, will most likely be infrequent enough not to increase code size nearly as much. We'll know for sure after the #5849 and #5852 pending "improvements".