jvm - scala specialization - using object instead of class causes slowdown? -

i've done benchmarks , have results don't know how explain.

the situation in nutshell:

i have 2 classes doing same (computation heavy) thing generic arrays, both of them use specialization (@specialized, later @spec). 1 class defined like:

class [@spec t] {   def a(d: array[t], c: whatever[t], ...) = ...   ... } 

second: (singleton)

object b {   def a[@spec t](d: array[t], c: whatever[t], ...) = ...   ... } 

and in second case, huge performance hit. why can happen? (note: @ moment don't understand java bytecode well, , scala compiler internals too.)

more details:

full code here: https://github.com/magicgoose/trashbox/tree/master/sorting_tests/src/magicgoose/sorting sorting algorithm ripped java, (almost)automagically converted scala , comparison operations changed generic ones allow using custom comparisons primitive types without boxing. plus simple benchmark (tests on different lengths, jvm warmup , averaging)
results looks like: (left column original java arrays.sort(int[]))

     javasort                    |      javasortgen$mci$sp          |      javasortgensingleton$mci$sp length 2        | time 0.00003ms | length 2        | time 0.00004ms | length 2        | time 0.00006ms length 3        | time 0.00003ms | length 3        | time 0.00005ms | length 3        | time 0.00011ms length 4        | time 0.00005ms | length 4        | time 0.00006ms | length 4        | time 0.00017ms length 6        | time 0.00008ms | length 6        | time 0.00010ms | length 6        | time 0.00036ms length 9        | time 0.00013ms | length 9        | time 0.00015ms | length 9        | time 0.00069ms length 13       | time 0.00022ms | length 13       | time 0.00028ms | length 13       | time 0.00135ms length 19       | time 0.00037ms | length 19       | time 0.00040ms | length 19       | time 0.00245ms length 28       | time 0.00072ms | length 28       | time 0.00060ms | length 28       | time 0.00490ms length 42       | time 0.00127ms | length 42       | time 0.00096ms | length 42       | time 0.01018ms length 63       | time 0.00173ms | length 63       | time 0.00179ms | length 63       | time 0.01052ms length 94       | time 0.00280ms | length 94       | time 0.00280ms | length 94       | time 0.01522ms length 141      | time 0.00458ms | length 141      | time 0.00479ms | length 141      | time 0.02376ms length 211      | time 0.00731ms | length 211      | time 0.00763ms | length 211      | time 0.03648ms length 316      | time 0.01310ms | length 316      | time 0.01436ms | length 316      | time 0.06333ms length 474      | time 0.02116ms | length 474      | time 0.02158ms | length 474      | time 0.09121ms length 711      | time 0.03250ms | length 711      | time 0.03387ms | length 711      | time 0.14341ms length 1066     | time 0.05099ms | length 1066     | time 0.05305ms | length 1066     | time 0.21971ms length 1599     | time 0.08040ms | length 1599     | time 0.08349ms | length 1599     | time 0.33692ms length 2398     | time 0.12971ms | length 2398     | time 0.13084ms | length 2398     | time 0.51396ms length 3597     | time 0.20300ms | length 3597     | time 0.20893ms | length 3597     | time 0.79176ms length 5395     | time 0.32087ms | length 5395     | time 0.32491ms | length 5395     | time 1.30021ms 

the latter 1 defined inside object , it's awful (about 4 times slower).

update 1

i've run benchmark , without scalac optimise option, , there no noticeable differences (only slower compilation optimise).

it's 1 of many bugs in specialization--i'm not sure whether one's been reported on bug tracker or not. if throw exception sort, you'll see calls generic version not specialized version of second sort:

java.lang.exception: boom!     @ magicgoose.sorting.dualpivotquicksortgensingleton$.magicgoose$sorting$dualpivotquicksortgensingleton$$sort(dualpivotquicksortgensingleton.scala:33)     @ magicgoose.sorting.dualpivotquicksortgensingleton$.sort$mfc$sp(dualpivotquicksortgensingleton.scala:13) 

note how top thing on stack dualpivotquicksortgensingleton$$sort(...) instead of ...sort$mfc$sp(...)? bad compiler, bad!

as workaround, can wrap private methods inside final helper object, e.g.

def sort[@ spec t](a: array[t]) { helper.sort(a,0,a.length) } private final object helper {   def sort[@spec t](a: array[t], i0: int, i1: int) { ... } } 

for whatever reason, compiler realizes ought call specialized variant. haven't tested whether every specialized method called needs inside own object; i'll leave via exception-throwing trick.