Return-Path: 
 <dev-return-29948-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org>
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 42872 invoked from network); 17 Oct 2007 15:33:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Oct 2007 15:33:11 -0000
Received: (qmail 82352 invoked by uid 500); 17 Oct 2007 15:32:55 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 82332 invoked by uid 500); 17 Oct 2007 15:32:55 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@harmony.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@harmony.apache.org>
List-Post: <mailto:dev@harmony.apache.org>
List-Id: <dev.harmony.apache.org>
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 82323 invoked by uid 99); 17 Oct 2007 15:32:55 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 08:32:55 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.90.177 as permitted sender)
Received: from [66.249.90.177] (HELO ik-out-1112.google.com) (66.249.90.177)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 15:32:58 +0000
Received: by ik-out-1112.google.com with SMTP id c30so1320003ika
        for <dev@harmony.apache.org>; Wed, 17 Oct 2007 08:32:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        bh=T8dT4Qt6nqGByIfUA6EYXLMXNZgBOd5czij+S9oXSr4=;
        b=Y/Uuad5EJ0J9xD5ByZ+pKFUE2uahLlRmJy7gGM1gILUaWMdi8z0NnctucicKYqfymf6MpBNG7Rdc7XPZN/f/0oUGf84TMBGxc9LhKb53Iv9+LdJMWnORFWyrGwyuXQd5nhemS+Ljlx5qZlqOpDeKVdT1tdDRQewGEejcyWB5u3I=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=IIs/3bY8zgjxq+NhHgHqzJxMWc6v5SLFVO3FF3/GAg2xaa0ERe0xuTck961zjagd3Dgx3Dp/wd28eF5HvfL+96xoZLXkSQ9axtM7nzNbPzGKtk0MLmrno72tKMidXg1DFRY+Ob9dZzw9rg4LYitxIDH8RqLZ4p16Aa7JDuaR0nk=
Received: by 10.150.136.6 with SMTP id j6mr1691169ybd.1192635156174;
        Wed, 17 Oct 2007 08:32:36 -0700 (PDT)
Received: from ?9.20.183.67? ( [195.212.29.75])
        by mx.google.com with ESMTPS id 7sm27764nfv.2007.10.17.08.32.33
        (version=SSLv3 cipher=RC4-MD5);
        Wed, 17 Oct 2007 08:32:34 -0700 (PDT)
Message-ID: <47162B08.1040907@gmail.com>
Date: Wed, 17 Oct 2007 16:32:24 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib][icu] Bringing ICU level up to 3.8
References: <4700CBA0.1090304@googlemail.com>
	 <2c9597b90710012237q487c4c53gf019a85b1f8f6edb@mail.gmail.com>
	 <470214B1.2070000@googlemail.com>
	 <211709bc0710072201h41f42c74uf67d9f70599bd16b@mail.gmail.com>
	 <4709F829.3060002@googlemail.com>
	 <211709bc0710081939u73797ce9we64c2225f8d0c818@mail.gmail.com>
	 <470E460D.7030506@googlemail.com>
 <2c9597b90710161034u7edf91c2gb261a23a84ef095e@mail.gmail.com>
 <4715F631.5040701@gmail.com>
In-Reply-To: <4715F631.5040701@gmail.com>
X-Enigmail-Version: 0.95.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Tim Ellison wrote:
> (Left as an exercise for the reader <g>)

Feeling a bit guilty about the cop-out...

I slightly modified Alexei's test case to
 - include some warm-up encode/decode loops to get the methods
   jitted to a reasonable level,
 - read the data into a direct byte buffer, and then into a
   'regular' byte buffer, e.g. one allocated in the Java heap,
 - I then looked at the effect of converting a short string (129 chars)

I was running this on the IBM VME, and here's what I got (below).

Interestingly the Java decoder was faster on the long string than the
native code.  The others are sufficiently similar to imply to me that we
should just keep it all in Java.


=== long string

Read chars = 3285165
10 loops warm up
10 loops timed

Direct ByteBuffer

Built-in
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 781
millis
<org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 571
millis


Java Heap Byte Buffer

Built-in
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 430
millis
<org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 521
millis


=== short string

Read chars = 129
1000 loops warm-up
10000 loops timed


Direct ByteBuffer

Built-in
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 10
millis
<org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 0 millis


Java Heap Byte Buffer

Built-in
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time: 10
millis
<org.apache.harmony.niochar.charset.CP_1251$Encoder> Encoding time: 0 millis