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] Commented: (DERBY-909) Improve performance of String literals in statements
Date Fri, 08 Jan 2010 13:54:54 GMT

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

Knut Anders Hatlen commented on DERBY-909:

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
> 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 is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message