Return-Path: Delivered-To: apmail-mina-dev-archive@www.apache.org Received: (qmail 95735 invoked from network); 12 Dec 2009 01:33:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Dec 2009 01:33:41 -0000 Received: (qmail 70646 invoked by uid 500); 12 Dec 2009 01:33:41 -0000 Delivered-To: apmail-mina-dev-archive@mina.apache.org Received: (qmail 70557 invoked by uid 500); 12 Dec 2009 01:33:40 -0000 Mailing-List: contact dev-help@mina.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mina.apache.org Delivered-To: mailing list dev@mina.apache.org Received: (qmail 70545 invoked by uid 99); 12 Dec 2009 01:33:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Dec 2009 01:33:40 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Dec 2009 01:33:39 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 1C025234C04C for ; Fri, 11 Dec 2009 17:33:18 -0800 (PST) Message-ID: <1561021802.1260581598100.JavaMail.jira@brutus> Date: Sat, 12 Dec 2009 01:33:18 +0000 (UTC) From: "Bogdan Pistol (JIRA)" 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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DIRMINA-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789643#action_12789643 ] Bogdan Pistol commented on DIRMINA-751: --------------------------------------- using Emmanuel's raw code suggestion passes the tests: if (requestedCapacity < 0) { return Integer.MAX_VALUE; } int newCapacity = Integer.highestOneBit(requestedCapacity); newCapacity <<= (newCapacity < requestedCapacity ? 1 : 0); return (newCapacity < 0 ? Integer.MAX_VALUE : newCapacity); > 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, 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.