Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <3718558.332871285120832845.JavaMail.jira@thor>
Date: Tue, 21 Sep 2010 22:00:32 -0400 (EDT)
From: "Tim Ellison (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Resolved: (HARMONY-6635) FloatingPointParser uses
 toLowerCase unnecessarily
In-Reply-To: <13317014.1301282810913652.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Ellison resolved HARMONY-6635.
----------------------------------

         Assignee: Tim Ellison
    Fix Version/s: 5.0M15
       Resolution: Fixed

Fair comment, so I changed it to parse
"0x1.P1", "0x113D4cc.P22", "3.141592654", "2.7182818284590452353602875"

and the results were as follows:

Current code, runs (ms) = 1281, 1266, 1360, 1390, 1266
New code, runs (ms) = 1156, 1157, 1141, 1141, 1157

Seems to show the new code is faster, but given I'm doing 40k parses here I'm not claiming its going to make a huge difference unless your application is really hammering the parse code.

I applied the patch to the LUNI module at repo revision r999724.

Gaz please can you confirm this is fixed to your satisfaction?


> FloatingPointParser uses toLowerCase unnecessarily
> --------------------------------------------------
>
>                 Key: HARMONY-6635
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6635
>             Project: Harmony
>          Issue Type: Improvement
>         Environment: Android 2.2
>            Reporter: Gaz Davidson
>            Assignee: Tim Ellison
>             Fix For: 5.0M15
>
>         Attachments: harmony-6635.patch
>
>
> A lot of time is being eaten inside FloatingPointParser.java calling String.toLowerCase when testing for "hex float" types.
> > if (s.toLowerCase().indexOf("0x") != -1) 
> I imagine that such hex float numbers are very rare, so this is a huge waste of time in the general case.
> I haven't tested this, but it looks to me like the string is already trimmed and so checking at a specific location should speed this up considerably:
> > if (s.size() > 2 && s.charAt(0) =='0' && (s.charAt(1) == 'x' || s.charAt(1) == 'X')) 

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