Jesse Wilson wrote:
On Mon, Sep 28, 2009 at 1:58 AM, Regis Xu (JIRA) <j...@apache.org> wrote:
In my understanding, SelectorBenchmark.java try to simulate a "real"
scenario of using selector, so I picked benchmark from HARMONY-4879 which
*only* test Selector.selectNow(), the result:
svn + no mapping
clients/active per 100 10
100 1318 1102
500 8325 7612
1000 20083 18235
1500 33486 29643
svn
clients/active per 100 10
100 924 643
500 6465 5206
1000 16494 12250
1500 28537 20684
the gap is obvious. While micro benchmark just said a side of words, we
would like that it could work better in real world, I may need more time to
do more test.
From a quick glance, this microbenchmark doesn't appear to test changes to
the selected keys set. Since that's the reason for maintaining the indices,
it doesn't feel like a representative benchmark.
I think "changes to the selected keys set" doesn't help to show more things.
Because there is no much difference in processSelectResult. And the reason for
maintaining readableFDs/writableFDs and mapping is avoiding O(num(keys)) in
Selector.select() [1]
What do you think?
[1] https://issues.apache.org/jira/browse/HARMONY-4869
That said, the benchmark does show that iterating the full keyset has its
cost.
I don't see reason to keep the previous select() method.
I'd like the old one to call the new one, so other places depend on old
interface can work without modifications.
There's only one other caller, so I'd prefer to just fix that.
I found processing a .zip of git patches quite cumbersome to work with.
I just think small patches are easy to review, because one patch only do
one simple thing. What form of patches do you prefer? I think git can help
me to do that :)
Cool, and I agree that compartmentalized changes are good. Applying and
diffing six patches just seemed labour-intensive for what I think of as one
logical change.
--
Best Regards,
Regis.
