A possible core speedup

[Marshall Schor <ms...@schor.com>]

I'm not sure this would speed anything up - but just in case:

While doing some profiling, it appears that some time is spent (during
deserializing) in CasImpl's ll_getTypeClass.  This code is a big switch
statement written as a series of "if" statements, testing the current
typeSystemImpl instance's set of values for primitive type codes.

Switch can't be used here because the "case" values must be constants. 
I think all the built-in type codes are constant - but the
implementation seems to be allowing them to change (they're referenced
from the TypeSystemImpl instance, as non-final values). 

Using constants would probably speed up this function quite a bit.  Any
reasons anyone sees we couldn't/shouldn't change this to use constants?

-Marshall

Re: A possible core speedup

[Thilo Goetz <tw...@gmx.de>]

I was half way through writing a reply when my email client
crashed.  Oh well.  Here's the abbreviated version.  There's
nothing wrong with this in principle, just check the comments
on CASImpl.setupTSDefault().  Make sure that the constants
actually correspond to the order in which types are created.

Also check the TYPE_CLASS constants.  They may actually have
the correct values for the built-in types, not sure.

I doubt you'll get a big speed-up out of this, though.  Let
us know what you find.

--Thilo

Marshall Schor wrote:
> I'm not sure this would speed anything up - but just in case:
> 
> While doing some profiling, it appears that some time is spent (during
> deserializing) in CasImpl's ll_getTypeClass.  This code is a big switch
> statement written as a series of "if" statements, testing the current
> typeSystemImpl instance's set of values for primitive type codes.
> 
> Switch can't be used here because the "case" values must be constants. 
> I think all the built-in type codes are constant - but the
> implementation seems to be allowing them to change (they're referenced
> from the TypeSystemImpl instance, as non-final values). 
> 
> Using constants would probably speed up this function quite a bit.  Any
> reasons anyone sees we couldn't/shouldn't change this to use constants?
> 
> -Marshall