|
|
behold the mythical unapplyProd: it does not exist, yet it promises to speed up pattern matching on case classes
instead of calling the synthetic unapply/unapplySeq, we don't call the mythical synthetic unapplyProd,
since -- if it existed -- it would be the identity anyway for case classes
eventually, we will allow user-defined unapplyProd's, which should give you almost the same speed as case class matching
for user-defined extractors (i.e., you don't have to wrap in an option, just return something on which we can select _i for i = 1 to N, unless it is null, which indicates match failure)
still need to figure out a way to derive the types for the subpatterns, without requiring you to wrap your result in a ProductN
unapplyProd support for vararg case classes
using caseFieldAccessors instead of synthetic _i
now the compiler bootstraps again, and after this optimization, quick.lib overhead is 70%, quick.comp is 50%
(compiling with a locker built using -Yvirtpatmat, and itself generating code for -Yvirtpatmat)
before the optimization, I think the overhead for quick.comp was close to 100% in this scenario
more robust tupleSel for case classes
TODO:
- pos/t602 -- clean up after type inference as in fromCaseClassUnapply
- run/pf-catch -- implement new-style orElse for partial function in uncurry
|
