harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-4869) [classlib][nio][performance] Selector improvements: moving away from O(n) at Java layer, part 1
Date Fri, 28 Sep 2007 19:23:50 GMT

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

Aleksey Shipilev updated HARMONY-4869:
--------------------------------------

    Description: 
Current implementation of java.nio.channels.Selector is O(n) for Selector.select() operation.

There are several causes:
 1. "keys" is the HashSet, so we spend time on iterating over it
 2. "keys" are iterated on every select() to prepare the readable and writable arrays for
native call

This patch includes a bunch of optimizations:
 1. Creates hashCode() and equals() for SelectionKeyImpl to get rid of calling _native_ identityHashCode()
 2. Changes the internal representation of keys to SelectionKeyImpl[] and adds logic for on-the-fly
maintenance
 3. Adds on-the-fly maintenance for readable and writable arrays, making them prepared right
away for every select()
 4. Adds indexes for easy mapping "keys<->FD"
 5. Optimizes hotpath in processResults().

Keeping in mind that count(register) <= count(select), we sure that moving key set maintenance
to register() is performance-safe.

Thus, we simplify one part of Selector.select() call from being O(n) in the Java layer. There
are also processResults() scales as O(n) and still portlib and native layers too - they're
going to be optimized later too.

  was:
Current implementation of java.nio.channels.Selector is O(n) for Selector.select() operation.

There are several causes:
 1. keys is the HashSet, so we spend time on iterating over it
 2. keys are iterated on every select() to prepare the readable and writable arrays for native
call

This patch includes a bunch of optimizations:
 1. Creates hashCode() and equals() for SelectionKeyImpl to get rid of calling _native_ identityHashCode()
 2. Changes the internal representation of keys to SelectionKeyImpl[] and adds logic for on-the-fly
maintenance
 3. Adds on-the-fly maintenance for readable and writable arrays, making them prepared right
away for every select()
 4. Adds indexes for easy mapping of keys<->FD
 5. Optimizes hotpath in processResults().

Keeping in mind that count(register) <= count(select), we sure that moving maintenance
to register() is performance-safe.

Thus, we simplify one part Selector.select() from being O(n) in the Java layer, not saying
about processResults() - to be optimized later. Overall Selector.select() call is still O(n)
because of portlib and native layers - to be optimized later too.


> [classlib][nio][performance] Selector improvements: moving away from O(n) at Java layer,
part 1
> -----------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-4869
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4869
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: all
>            Reporter: Aleksey Shipilev
>         Attachments: selectors-JL-O1.patch
>
>
> Current implementation of java.nio.channels.Selector is O(n) for Selector.select() operation.

> There are several causes:
>  1. "keys" is the HashSet, so we spend time on iterating over it
>  2. "keys" are iterated on every select() to prepare the readable and writable arrays
for native call
> This patch includes a bunch of optimizations:
>  1. Creates hashCode() and equals() for SelectionKeyImpl to get rid of calling _native_
identityHashCode()
>  2. Changes the internal representation of keys to SelectionKeyImpl[] and adds logic
for on-the-fly maintenance
>  3. Adds on-the-fly maintenance for readable and writable arrays, making them prepared
right away for every select()
>  4. Adds indexes for easy mapping "keys<->FD"
>  5. Optimizes hotpath in processResults().
> Keeping in mind that count(register) <= count(select), we sure that moving key set
maintenance to register() is performance-safe.
> Thus, we simplify one part of Selector.select() call from being O(n) in the Java layer.
There are also processResults() scales as O(n) and still portlib and native layers too - they're
going to be optimized later too.

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


Mime
View raw message