harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Tue, 29 Sep 2009 08:20:53 GMT
Jesse Wilson wrote:
> On Mon, Sep 28, 2009 at 1:58 AM, Regis Xu (JIRA) <jira@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.

Mime
View raw message