[ 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
