db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-909) Improve performance of String literals in statements
Date Wed, 05 Feb 2014 09:04:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798014#comment-12798014
] 

Knut Anders Hatlen edited comment on DERBY-909 at 2/5/14 9:03 AM:
------------------------------------------------------------------

For the record, I tried the naive approach of changing CharConstantNode.generateConstant()
to generate byte code equivalent to this Java code:

  (String) activation.getPreparedStatement().getSavedObject(idx)

It worked for some queries, and failed with a NullPointerException in others. (For example,
VALUES 'abc' failed with NPE.) The problem appeared to be that the generated code could be
executed before the activation had been initialized properly, so that the prepared statement
was null.

See also this comment in UserTypeConstantNode, describing what looks like the same problem:

{code}
        // The code generated here is invoked when the generated class is constructed. However
the prepared statement
        // is not set into the activation class when it is constructed, but later. So we cannot
use the getSavedObject
        // method to retrieve the value.
//         else if( value instanceof DataValueDescriptor)
//         {
//             acb.pushThisAsActivation( mb);
//             mb.callMethod( VMOpcode.INVOKEINTERFACE,
//                            null,
//                            "getPreparedStatement",
//                            ClassName.ExecPreparedStatement,
//                            0);
//             mb.push( acb.addItem( value));
//             mb.callMethod( VMOpcode.INVOKEINTERFACE,
//                            null,
//                            "getSavedObject",
//                            "java.lang.Object",
//                            1);
//             mb.cast( fieldType);
//         }
{code}


was (Author: knutanders):
For the record, I tried the naive approach of changing CharConstantNode.generateConstant()
to generate byte code equivalent to this Java code:

  (String) activation.getPreparedStatement().getSavedObject(idx)

It worked for some queries, and failed with a NullPointerException in others. (For example,
VALUES 'abc' failed with NPE.) The problem appeared to be that the generated code could be
executed before the activation had been initialized properly, so that the prepared statement
was null.

See also this comment in UserTypeConstantNode, describing what looks like the same problem:

        // The code generated here is invoked when the generated class is constructed. However
the prepared statement
        // is not set into the activation class when it is constructed, but later. So we cannot
use the getSavedObject
        // method to retrieve the value.
//         else if( value instanceof DataValueDescriptor)
//         {
//             acb.pushThisAsActivation( mb);
//             mb.callMethod( VMOpcode.INVOKEINTERFACE,
//                            null,
//                            "getPreparedStatement",
//                            ClassName.ExecPreparedStatement,
//                            0);
//             mb.push( acb.addItem( value));
//             mb.callMethod( VMOpcode.INVOKEINTERFACE,
//                            null,
//                            "getSavedObject",
//                            "java.lang.Object",
//                            1);
//             mb.cast( fieldType);
//         }


> Improve performance of String literals in statements
> ----------------------------------------------------
>
>                 Key: DERBY-909
>                 URL: https://issues.apache.org/jira/browse/DERBY-909
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>              Labels: derby_triage10_11
>
> String literals (constants) go through this process currently
> Create String object from within parser
> Serialized String into generated class file as UTF-8 (taking up two constant pool entries)
> Unserialize and intern String from generated class at class load time
> The serialize into the class file and un-serialize can be avoided by saving  the String
in the saved object pool (see CompilerContext)
> This would benefit the common pattern we see in SQL scripts that load data like:
> insert into customer values (1, 'Fred', 'Flintstone');
> insert into customer values (2, 'Wilma'', 'Flintstone');
> etc.
> etc.
> Note these are poor performing in Derby compared to other databases.
> It would also be a step on the way to having a single compiled plan for such statements
that don't use parameter markers.
> Most likely the performance benefit with inserts will be small until DERBY-888 is fixed,
because with inserts the sync of the allocated pages dominates the cost.
> Possible newcomer task with guideance.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message