Return-Path: 
 <dev-return-29953-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org>
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 22763 invoked from network); 17 Oct 2007 21:59:05 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 17 Oct 2007 21:59:05 -0000
Received: (qmail 98436 invoked by uid 500); 17 Oct 2007 21:58:52 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 97912 invoked by uid 500); 17 Oct 2007 21:58:51 -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 97898 invoked by uid 99); 17 Oct 2007 21:58:51 -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 14:58:51 -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 vstrigun@gmail.com designates
 64.233.182.188 as permitted sender)
Received: from [64.233.182.188] (HELO nf-out-0910.google.com) (64.233.182.188)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 21:58:55 +0000
Received: by nf-out-0910.google.com with SMTP id k4so2156948nfd
        for <dev@harmony.apache.org>; Wed, 17 Oct 2007 14:58:15 -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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        bh=fEN+Q+V9oscPjEoUJqRIAzBtTCUR1pTcOR+rdoBKuKY=;
        b=l7oJHdL6tXN41qihQp28OvpAz/rxHDatikOt62bHntKT9ypyjtcHtlBJAlun019lLmSlR17B5L5a471nlNPd56HMBG37Uj6S2H8DdL5s+vl7y3DbEkDohxamCrmFJQSbP+XnJHs0fOwXq01zU0ZAa7DrKyywcZ9YwdKdU6Q/Hc8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=R2jXCg3gwBKwK90gsa0XwQbm5yB7b4tu5b7Cnpw6EFp7BTqXs+oMNpqND6R36YzYANKNMDz352Ml29VTCJOA68YJVdv7vV2pFfIBkrUi+/nBeBrKkOiznmKp7hBpkIqBHDlrqd9y3DsYAqbPDao9JmdojDoV/2X+0ZdQkXZgXq0=
Received: by 10.78.173.20 with SMTP id v20mr593795hue.1192658295337;
        Wed, 17 Oct 2007 14:58:15 -0700 (PDT)
Received: by 10.78.53.16 with HTTP; Wed, 17 Oct 2007 14:58:15 -0700 (PDT)
Message-ID: <e3b630230710171458o37524870o4821d65829f690c4@mail.gmail.com>
Date: Thu, 18 Oct 2007 01:58:15 +0400
From: "Vladimir Strigun" <vstrigun@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][icu] Bringing ICU level up to 3.8
In-Reply-To: <47162B08.1040907@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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> <47162B08.1040907@gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

On 10/17/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
> 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
>

I'm a little bit confused about the results.
I tried to run the test (slughtly modified) on DRLVM and got the next results:
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
2844 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1797 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1578 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1203 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(j):
1125 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
5328 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
1906 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
797 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
609 millis
<org.apache.harmony.niochar.charset.CP_1251$Decoder> Decoding time(d):
672 millis

Input length were 8 bytes, 128, 8kb, 16k and 128k correspondingly. (j)
means java buffer, (d) - direct byte buffer. It seems that native
decoding faster for big buffers, whereas Java part works fine for
small input.

Thanks.
Vladimir.