Search code examples
javadrools

Performance of primitive vs. non-primitive data types in Drools

I was wondering what would be the implications on performance and memory usage of using primitives compared to non-primitive data types in Drools.

In documentation, it is stated:

8.8.6. A Note on Auto-boxing and Primitive Types Drools attempts to preserve numbers in their primitive or object wrapper form, so a variable bound to an int primitive when used in a code block or expression will no longer need manual unboxing; unlike Drools 3.0 where all primitives were autoboxed, requiring manual unboxing. A variable bound to an object wrapper will remain as an object; the existing JDK 1.5 and JDK 5 rules to handle auto-boxing and unboxing apply in this case. When evaluating field constraints, the system attempts to coerce one of the values into a comparable format; so a primitive is comparable to an object wrapper.

Basically, in my rules, I have conditions such as:

$someObj : SomeObj( someIntOrIntegerField > 15 )

and accumulations as follows:

$total : Double() from accumulate (
                 SomeObj(
                    $someIntOrIntegerField : someIntOrIntegerField) over window:time( 1h ),
                 sum( $someIntOrIntegerField ) )

What I understand is that Drools delegates coercion to JVM and does not do any boxing/unboxing. Is this true? As I am racing against time in couple of milliseconds, I was wondering which would be faster:

int someIntOrIntegerField;

or

Integer someIntOrIntegerField;

Please note that my question is about if there's a boxing/unboxing which I am not aware of in Drools, and whether primitives or Objects would be faster and efficient(in terms of memory), again, limited to Drools. Otherwise, there's a good answer in general Java scope: https://softwareengineering.stackexchange.com/a/203971

Solution

  • The one part of your question that is answerable is this:

    What I understand is that Drools delegates coercion to JVM and does not do any boxing/unboxing. Is this true?

    No it is not true. The JVM does not perform autoboxing / unboxing conversions. It is the (source -> bytecode) compiler that is responsible for inserting calls to (for example) Integer.valueOf(int) and Integer.intValue() into the appropriate point in the bytecodes. You can verify this by using javap to examine the ".class" files.

    In the case of Drools, the the compiler produces ".class" files that have any necessary autoboxing / unboxing in the bytecodes. I think that the documentation you have quoted actually means that the Drools compiler's strategy for autoboxing / unboxing has changed ... since Drools 3.0