Mailing-List: contact dev-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mina.apache.org
Message-ID: <225450021.1260617718087.JavaMail.jira@brutus>
Date: Sat, 12 Dec 2009 11:35:18 +0000 (UTC)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@mina.apache.org
Subject: [jira] Commented: (DIRMINA-751) IoBuffer.normalizeCapacity
 improvement
In-Reply-To: <239797445.1260220098177.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DIRMINA-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789718#action_12789718 ] 

Emmanuel Lecharny commented on DIRMINA-751:
-------------------------------------------

I have applied the fix :
http://svn.apache.org/viewvc?rev=889927&view=rev

Some thoughts :
- we need a real unit test for IoBuffer. It has to be written as a Unit Test, with no main() method, and an Inner class to be able to test this normalizeCapacity method
- in MINA 3.0, the IoBuffer class will probably be removed, or refactored, as we don't really need all this mechanism, but this is more something we should discuss on the ML.
- the class hierarchy is probably overkilling. We should have a IoBuffer interface, an AbstractIoBuffer abstract class, move the IoBufferWrapper and ProxyHandshakeIoBuffer classes to be subclasses of the AbstractIoBuffer class.
- I'm not convinced that using the CachedBuffer brings any speed improvement. Trying to be smarter than the VM is most certainly a lost of time... IMO, this class should be removed.

Let's discuss all that on the ML for MINA 3.0 !

> IoBuffer.normalizeCapacity improvement
> --------------------------------------
>
>                 Key: DIRMINA-751
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-751
>             Project: MINA
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.0.0-RC1
>         Environment: N/A
>            Reporter: Bogdan Pistol
>            Priority: Minor
>             Fix For: 2.0.0-RC2
>
>         Attachments: IoBufferTest.java, IoBufferTest.java, patch.txt
>
>
> The technique of computing the minimum power of 2 that is bigger than the requestedCapacity in the org.apache.mina.core.buffer.IoBuffer.normalizeCapacity() is not optimal.
> The current computation is as follows:
>  int newCapacity = 1;
>         while ( newCapacity < requestedCapacity )  {
>             newCapacity <<= 1;
>             if ( newCapacity < 0 )   {
>                 return Integer.MAX_VALUE;
>             }
>         }
> The time complexity of this is O(n), where n is the number of bits of the requestedCapacity integer, that is log2(requestedCapacity) - maximum 31.
> This creates an unnecessary overhead in some high IoBuffer allocations scenarios that are calling IoBuffer.normalizeCapacity() a lot when creating IoBuffers. I observed this when benchmarking a MINA server with hprof.
> There is a better solution to this problem than to iterate the bits from 0 to log2(requestedCapacity).
> The alternative is to use a binary search technique that has optimal time complexity of O(5). Because requestedCapacity is an integer and has a maximum of 2^5 (32) bits we can binary search in the set of bits and determine in O(5) comparisons the minimum power of 2 that is bigger than the requestedCapacity.

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