db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Closed: (DERBY-4678) Avoid code duplication in GenericConglomerateController.fetch()
Date Mon, 31 May 2010 11:40:53 GMT

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

Knut Anders Hatlen closed DERBY-4678.

    Issue & fix info:   (was: [Patch Available])
          Resolution: Won't Fix

I changed the test to use a table with 1 million rows, and increased the size of the page
cache so that it could hold the entire table + index and reran the test. I also increased
the time each test ran from 20s+40s to 40s+60s (that is, 40s warmup, 60s data collection).
With 250 runs with each jar, I now see that the patched version gives 0.8% lower throughput
on average than trunk. I also added a variant where the calls to fetch/3 in IndexToBaseRowResultSet
are replaced with calls to fetch/4, and a 0.8% decrease was observed there as well.

Since these results show the averages of a fairly high number of runs, and they are also consistent
with some shorter test (20s+40s, 100 runs per jar) that I ran before this last experiment,
I think there's a high probability that the decrease we see is real, and not just random variation.
Having an extra method won't cause any big problems for DERBY-4676, so I guess it's not worthwhile
to make this change. I'm therefore closing the issue as Won't Fix.

(I see I didn't mention this in my previous comment, so, for the record, all the tests were
performed on a dual-cpu AMD Opteron running OpenSolaris 2009.06 and Sun's Java SE 6u20.)

> Avoid code duplication in GenericConglomerateController.fetch()
> ---------------------------------------------------------------
>                 Key: DERBY-4678
>                 URL: https://issues.apache.org/jira/browse/DERBY-4678
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: derby-4678-1a.diff, fetch.diff, FetchTest.java
> GenericConglomerateController has two methods named fetch(). One of these methods has
a parameter called waitForLock, whereas the other one doesn't have such a parameter. When
I diffed the two methods, the only difference I found, apart from a couple of whitespace diffs,
was that the method with the waitForLock parameter called lockPosititionForRead/lockPositionForWrite
using the parameter value, and the other method called them with a hard-coded value of true.
> To avoid duplication of code, fetch(RowLocation,DataValueDescriptor[],FormatableBitSet)
should forward calls to fetch(RowLocation,DataValueDescriptor[],FormatableBitSet,boolean).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message