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 Thu, 27 Sep 2007 16:25:51 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 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.

  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 Selector.select() from being O(n) to O(1) in the Java layer.
Overall Selector.select() call is still O(n) because of portlib and native layers - to be
optimized later.

        Summary: [classlib][nio][performance] Selector improvements: moving away from O(n)
at Java layer, part 1  (was: [classlib][nio][performance] Selector improvements: moving from
O(n) to O(1) at Java layer)

> [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 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.

-- 
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