[jira] Commented: (DERBY-1876) Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only, forward ResultSets

["Daniel John Debrunner (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-1876?page=comments#action_12436700 ] 
            
Daniel John Debrunner commented on DERBY-1876:
----------------------------------------------

JDBC requires that each execution of ps.executeQuery() returns a new ResultSet object, thus looking at the code within EmbedResultSet() constructor is worth while.
There are at least four sub-optimal pieces of code:

1) (long)stmt.getQueryTimeout() * 1000L;
     Each creation a multiplication by 1000 is executed, could be avoided by having the
     value in ms calculated once and stored in EmbedStatement when setQueryTimeout is called.

2) stmt.getResultSetConcurrency()
     This call checks the Statement object to see if it is open, but it must be open since it is creating a ResultSet. Can be avoided by having EmbedResultSet use the final field that holds the concurrency, if iw was made package protected.

3) final int columnCount = getMetaData().getColumnCount();
    This creates a ResultSetMetaData object that will not be used in the typical case (at least I think it will not be used). Using resultDescription.getColumnCount() would get the count with no object creation.

4) 		this.currentRow = factory.getValueRow(columnCount);
		currentRow.setRowArray(null);

The call to getValueRow() creates a ValueRow with a new DataValueDescriptor array within it, the next line nulls out the refrence to the array. Thus this creates a short lived object for no value. Possibly work around is to have currentRow use the array directly, or create a ValueRow with no array within it.

> Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only, forward ResultSets
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1876
>                 URL: http://issues.apache.org/jira/browse/DERBY-1876
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Performance
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>         Attachments: derby1876.java
>
>
> For simple ResultSet usage like:
> ResultSet rs = ps.executeQuery();
>       while (rs.next()) {
>               rs.getInt(1);
>               rs.getInt(2);
>               rs.getInt(3);
>        }
> rs.close();
> it would be interesting to see how much overhead could be removed with simple changes, or possibly removed if there was a simple ResultSet implementation for forward only, read-only ResultSet, and the more complete implementation for all other ResultSet types such as updateable and/or scrollable. Has introducing updateable ResultSets, for example, degraded the performance of read-only ResultSets? Could code be changed so that a typical read-only Resultset is not affected by the code required for richer ResultSets?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira