[
https://issues.apache.org/jira/browse/DERBY-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6075:
--------------------------------------
Attachment: Compile.java
Dag asked if there was any measurable performance improvement, so I ran a quick
and completely unscientific experiment with the attached Compile.java class.
The class repeatedly compiles the following statement:
select max(x) from (values 1,2,3) v(x)
(Why did I choose exactly this statement? Firstly, it doesn't touch any
physical tables, so it shouldn't need to involve store or dictionary when
compiling. Secondly, it calls an aggregate function, so I presume it will use
the data structure previously known as aggregateVector, and we get to exercise
at least some of the new code.)
The statement cache is disabled, so that the statement is actually compiled
each time prepareStatement() is called.
Running the test several times to filter out variance/noise, I seem to be
getting about 15-20% better results with 10.10.1.1 than with 10.9.1.0. (Test
environment: Java 7, Solaris 11.)
Now, there are many other changes between 10.9.1.0 and 10.10.1.1, so there's no
evidence that changing the collections improved compilation speed measurably.
But at the very least it looks like we're heading in the right direction. :)
> Use modern collections in impl/sql/compile
> ------------------------------------------
>
> Key: DERBY-6075
> URL: https://issues.apache.org/jira/browse/DERBY-6075
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.10.1.1
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: Compile.java, d6075-10a-aggregate-vectors.diff,
> d6075-11a-remaining-vectors.diff, d6075-12a-stack.diff,
> d6075-13a-unused-properties.diff, d6075-14a-dead-syntax.diff,
> d6075-15a-sqlgrammar-vectors.diff, d6075-16a-negative-test.diff,
> d6075-17a-rename-aggregate-vectors.diff, d6075-1a-CollectNodesVisitor.diff,
> d6075-2a-bindExpression.diff, d6075-3a-javadoc.diff,
> d6075-4a-parameterList.diff, d6075-5a-ordering.diff,
> d6075-6a-DMLModStatementNode.diff, d6075-7a-more-signatures.diff,
> d6075-8a-local-hashtables.diff, d6075-9a-hashtable-fields.diff
>
>
> The code in the org.apache.derby.impl.sql.compile package predates the Java
> Collections Framework and uses old-style collections like java.util.Vector
> and java.util.Hashtable. Since the old-style collection classes are used in
> many method signatures, it's difficult to use modern collection classes when
> adding new code.
> I suggest we switch to using interfaces (like java.util.List and
> java.util.Map) instead of specific classes in the signatures, so that we have
> more flexibility in choosing the right collection class for the job.
> Only changing the signatures would allow us to continue using Vector and
> Hashtable, since they implement the interfaces. However, I think it would be
> good to switch to ArrayList and HashMap in a second step. The instances in
> impl/sql/compile are not shared between threads, so we don't need the
> synchronization provided by the old-style classes. Switching to
> unsynchronized classes may make compilation slightly faster.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
