db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1876) Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only, forward ResultSets
Date Wed, 15 Aug 2007 00:33:30 GMT

     [ https://issues.apache.org/jira/browse/DERBY-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Daniel John Debrunner updated DERBY-1876:

    Attachment: ers_current_row.txt

>From an earlier comment:

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

The call to getValueRow() creates a ValueRow with a new DataValueDescriptor array within it,
the next line nulls out the reference to the array. Thus this creates a short lived object
for no value. 

ers_current_row.txt is a patch that changes how currentRow is used in EmbedResultSet. Now
it is null to indicate the ResultSet is not positioned on a row, or not null and it points
to the currrent row. The current row in the resultset is directly pointed to, which is what
previously occurred, though at the DVD[] level and not the Row level.

Running tests on the patch.

> Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only,
forward ResultSets
> -----------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1876
>                 URL: https://issues.apache.org/jira/browse/DERBY-1876
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Performance
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>         Attachments: derby1862.java, derby1876.java, ers_current_row.txt, timeout_colcount.diff
> 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.
You can reply to this email to add a comment to the issue online.

View raw message