Jesse Wilson wrote:
On Tue, Sep 29, 2009 at 1:20 AM, Regis <xu.re...@gmail.com> wrote:

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?


The optimizations moved work from selectNow() to register() and
SelectionKey.interestOps(). Microbenchmarks that don't exercise those

Actually it's not "move", there is no O(numKeys) in both register() and SelectionKey.interestOps(). And it's possible to optimize modKey() update index directly instead of calling delKey() and addKey(). But I must admit it's complicated.....

methods encourage the wrong kind of optimizations.

True, the benchmark from HY-4879 intend to show O(numKyes) is expensive, but SelectorBenchmark.java doesn't count SelectionKey.interestOps() neither, that's why I said we need more tests.


And the current code is allocation heavy. In select cycles where the number
of the ready keys changes, it allocates and copies O(numReadyKeys) memory.
Unfortunately, the 4879 benchmark doesn't include any of these allocations.


This can be resolved by the way used in your new patch: set "flags" as field and reuse it.


--
Best Regards,
Regis.

Reply via email to