Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Message-ID: <003e01c2762b$d695fba0$1219570f@ranier>
From: "Steve Loughran" <steve_l@iseran.com>
To: <axis-dev@xml.apache.org>
References: 
 <Pine.SOL.4.10.10210171545390.8554-100000@baldy.extreme.indiana.edu>
Subject: Re: Axis performance
Date: Thu, 17 Oct 2002 15:23:34 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Kenneth Chiu" <chiuk@cs.indiana.edu>
To: <axis-dev@xml.apache.org>
Sent: Thursday, October 17, 2002 2:08 PM
Subject: Re: Axis performance


> On Tue, 15 Oct 2002, Steve Loughran wrote:
> > Interesting to see that FP to ascii conversion takes so long; one of my
> > projects is very FP intensive. But this is an XML parser issue, not SOAP
> > stack per-se. Maybe I should look at using a JNI to msxml bridge rather
than
> > xerces/J for the old xml parser. The proposal to use a binary
representation
> > of FP is interesting; there are the ISO standard representations after
all,
> > but it does go against the fundamentals of both XML and XML Schema.
>
> A possible compromise which might be acceptable for
> scientific computing is to send the double as text, but
> include a hint which can be used to speed up the FP
> conversion.  We haven't investigated this yet, though.

What is the big bottlenect with FP conversion? Does the runtime multiply the
mantissa by ten every time a new digit comes in, then has to exponentiate it
with the exponential digits?

Maybe the trick would be send it as hex encoded network byte order doubles.
Use Float.intBitsToFloat() or Double.longBitsToDouble() to convert from the
bits to the number and back.

Actually, maybe just sending the stuff as long and int would suffice, though
that would be dangerously confusing to some people.

-steve