db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1876) Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only, forward ResultSets
Date Fri, 22 Sep 2006 10:23:41 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1876?page=comments#action_12436809 ] 
Knut Anders Hatlen commented on DERBY-1876:

Moving one level down in the code and looking at the internal ResultSet hierarchy (not java.sql.ResultSet)
could also be useful. I have noticed that garbage collection takes a lot of CPU time when
running simple select statements in Derby. Using DTrace to collect information about object
allocation, I observed that most of the garbage were objects of type TableScanResultSet. Although
many classes were instanciated more frequently, they were relatively small and didn't contribute
so much to the total number of bytes allocated. However, TableScanResultSet has almost ninety
fields, which probably means each object is at least 400 bytes, even when all fields are null.
Refactoring to reduce bare-object size would be good.

For instance, BasicNoPutResultSetImpl (one of TSRS's super classes) has a number of fields
to collect timing statistics: 1 boolean, 7 longs and 3 ints. That should be about 70 bytes
per object. To reduce garbage produced when timing is off, timing information could be factored
out into a statistics class. Then we only need one field in the result set class, and it could
be null when timing is off.

> 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


View raw message