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 from O(n) to O(1) at Java layer
Date Thu, 27 Sep 2007 16:18:51 GMT

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

Aleksey Shipilev updated HARMONY-4869:

    Attachment: selectors-JL-O1.patch

The patch.

> [classlib][nio][performance] Selector improvements: moving from O(n) to O(1) at Java
> ------------------------------------------------------------------------------------------
>                 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_
>  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.

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

View raw message