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] Created: (HARMONY-4869) [classlib][nio][performance] Selector improvements: moving from O(n) to O(1) at Java layer
Date Thu, 27 Sep 2007 16:18:50 GMT
[classlib][nio][performance] Selector improvements: moving from O(n) to O(1) at Java layer
------------------------------------------------------------------------------------------

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


Mime
View raw message