Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <12689579.1174805552321.JavaMail.jira@brutus>
Date: Sat, 24 Mar 2007 23:52:32 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1876) Investigate overhead of JDBC layer and
 compiled activation code for simple embedded read-only, forward ResultSets
In-Reply-To: <23291269.1158882142270.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen updated DERBY-1876:
--------------------------------------

    Attachment: timeout_colcount.diff

Attaching a simple patch to fix issue #1 and #3 mentioned above. I have not been able to measure any performance improvement, but I think it's a good change anyway. At least, it eliminates one call to EmbedResultSet.checkIfClosed() and one call to EmbedStatement.checkStatus() per creation of an EmbedResultSet instance.

> 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, 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.