Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <16601466.1191007430596.JavaMail.jira@brutus>
Date: Fri, 28 Sep 2007 12:23:50 -0700 (PDT)
From: "Aleksey Shipilev (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-4869) [classlib][nio][performance]
 Selector improvements: moving away from O(n) at Java layer, part 1
In-Reply-To: <4521034.1190909930977.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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