An open source coding group I participate in similarly wrote our own
faster float parsing:
http://code.google.com/p/skylight1/source/browse/trunk/SkylightOpenGL/src/skylight1/opengl/files/QuickParseUtil.java#23
Took parsing 1000 strings from 465ms to 12ms, although it just handles
what we need it
Convert the floats to int bits before storing them, then convert
back from int bits when you read them. Store the numbers as either
hex or decimal integers.
On Apr 14, 11:01 am, Paul pmmen...@gmail.com wrote:
I've got a bit of code in an app that reads XML String input (from the
SD Card), and
If you have the rest of the code in place, I'd be reluctant to toss it out
and start over with a SQLite implementation. Although it might do the
conversion for free, it's going to be a much more general-purpose
conversion routine, and thus is unlikely to be as fast as one you've
optimized for
I haven't see the native part, but it's probably only useful for two things:
1 - Doing the final scaling by a power of ten, being able to handle very
large or very small exponent values.
You could have your own lookup table for the range you need, say from
10^-20 to 10^30, and use it when
The XML is the storage venue - Paths are drawn to the screen from the
XML, and users can add new Paths (written back to the XML) or delete
existing Paths (data is deleted from XML).
On Apr 14, 12:11 pm, Marcin Orlowski webnet.andr...@gmail.com wrote:
Any suggestions welcome!
How often the
I think this may be what Marcin was suggesting -- if the same float value
tends to appear multiple times, then when you parse a new one put it into a
cache. When you read strings, first see if the string is already in the
cache to retrieve the previously parsed float value for it.
Also can you
Ah, I see, create a kind of mapping from String - float, and first
check the mapping before performing the conversion?
Here is what traceview is telling me for the calls to Float.valueOf():
java/lang/Float.valueOf (Ljava/lang/String;)Ljava/lang/Float;
* self = 1.9%
* java/lang/Float.parseFloat
On 14 April 2011 20:43, Paul pmmen...@gmail.com wrote:
Ah, I see, create a kind of mapping from String - float, and first
check the mapping before performing the conversion?
Try to go as simple as possible. The less logic the faster is would possibly
go. How is your data modified? By just
I think Diane clarified what you were suggesting Marcin, thanks for
the input. Any suggestions as to the caching structure? I'd need
something with inexpensive lookups, yet can grow as I add pairings to
the cache.
Thanks,
Paul
On Apr 14, 12:11 pm, Marcin Orlowski webnet.andr...@gmail.com
Well, here is what I am dealing with, The XML file is actually an XML-
defines SVG file that represents a vector drawing. It is a requirement
that the files remain in SVG, as the user will be loading and
unloading these files on and off of the device, editing and viewing
them with my app. So we
What do String.toLowerCase(String) and StringBuilder have to do with
parsing a floating point number?
-- Kostya
14.04.2011 22:43, Paul пишет:
Ah, I see, create a kind of mapping from String - float, and first
check the mapping before performing the conversion?
Here is what traceview is
That was my thinking exactly - from the trace, a HUGE portion (~80%!)
of the conversion time is spent on string operations that wouldn't
seem to be needed. I couldn't find any link to a native routine via
the traceview.
On Apr 14, 3:26 pm, Kostya Vasilyev kmans...@gmail.com wrote:
What do
On Thu, Apr 14, 2011 at 3:34 PM, Paul pmmen...@gmail.com wrote:
That was my thinking exactly - from the trace, a HUGE portion (~80%!)
of the conversion time is spent on string operations that wouldn't
seem to be needed. I couldn't find any link to a native routine via
the traceview.
The
What version of the platform are you running on? It looks like in the
current source most of the function is written in native code, but there is
no native code in your profiling. I don't work on Dalvik, so I don't know
when the native impl appeared.
If this is the original Harmony
Thanks for the link, Mark.
StringBuilder, line 137:
s = s.substring(start, decimal) + s.substring(decimal + 1, end);
That's a memory allocation, or more like two or three - just to be able
to call Integer.parseInt() ignoring the period character.
Other interesting things:
end =
Sorry, should have mentioned this, this is 2.2 running on a Galaxy
Tab.
Based on Mark and Kostya's suggestions, I might just try to trim the
source and see what I can come up with - might be easier than managing
a mapping structure and will surely be lighter memory wise.
Will post back here with
OK, have stripped the FloatingPointParser bare, but can't run it as
the native method, parseFltImpl() is throwing an
UnsatisfiedLinkError...
Maybe a silly question, but any ideas what to do from here?
On Apr 14, 4:57 pm, Paul pmmen...@gmail.com wrote:
Sorry, should have mentioned this, this is
On Thu, Apr 14, 2011 at 7:47 PM, Paul pmmen...@gmail.com wrote:
OK, have stripped the FloatingPointParser bare, but can't run it as
the native method, parseFltImpl() is throwing an
UnsatisfiedLinkError...
Maybe a silly question, but any ideas what to do from here?
Start from scratch, as Gaz
Here is a simple class to convert a string in from 1234.4567 into a
floating point.
It doesn't support hexadecimal or 1E23 notations but it is here to
show the idea
===
public class String2Float {
final int max_exp = 38;
final int max_str_len = 20;
public class String2Float {
final int max_exp = 38;
final int max_str_len = 20;
float [] values;
char [] buffer;
public String2Float() {
buffer = new char [max_str_len + 1];
values = new float [max_exp + 1];
Sorry about double posting :(
BTW the performance of this method is about 10 times better.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this
Is a SQLite database not appropriate in such a scenario? You'd get the
conversion for free...
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this
I'd be interested to see how an SQLite implementation could work - you
could define each SVG document in a table, and then each shape from
that document in a second table, but where it would start to get
complicated would be that each shape each shape type has unique
properties. For instance, for
23 matches
Mail list logo
