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

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 10.6.1.0
• Fix Version/s: 10.6.1.0
• Component/s: JDBC
• Bug behavior facts: Performance
• Assignee: Unassigned
• Reporter: Daniel John Debrunner
• Created: 21/Sep/06 23:41
• Updated: 21/Jan/11 18:27
• Resolved: 28/Apr/10 17:33

Description

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?

Issue Links

• incorporates: DERBY-3004 Get rid of the finalizer in EmbedResultSet
• is related to: DERBY-1879 Save meta data related information for an EmbedResultSet at the plan level instead of the ResultSet level improves performance.
• relates to: DERBY-2139 executing getXXX() for a column checks the column position is in range three times, reduce to one.
• relates to: DERBY-827 Performance can be improved by re-using language ResultSets across Activation executions.
• relates to: DERBY-1957 Factor out run-time statistics information from language ResultSet classes