harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
Subject Re: [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Mon, 28 Sep 2009 19:46:09 GMT
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.

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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message