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 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 (Ljava/lang/String;)F = 94.3%

  ** self = 1.3%
  ** org/apache/harmony/luni/util/FloatingPointParser.parseFloat (Ljava/
lang/String;)F = 98.7%

  *** self = 6.5%
  *** org/a.../h.../luni/util/FloatingPointParser.initialParse (Ljava/
lang/String;I)Lorg/a.../h.../luni/util/FloatingPointParser
$StringExponentPair = 58.7%

  **** self = 29.9%
  **** a bunch of StringBuilder calls ~= 60%

  *** java/lang/String.toLowerCase ()Ljava/lang/String = 26.8%

  * java/lang/Float.valueOf (F)Ljava/lang/Float; = 3.8%

  ** self = 48.4%
  ** java/lang/Float.<init>  (F)V = 51.2%

  *** self = 69.7%
  *** java/lang/Number.<init>  ()V = 30.3%

Paul

On Apr 14, 2:20 pm, Dianne Hackborn<hack...@android.com>  wrote:
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 get profiling data for where most of the time is spent inside
of Float.parseFloat()?  In at least the current code base, the bulk of the
work for that is already done in native code.  It would be interesting to
know if most of your time is spent in that native function or the glue
around it.

It would also be useful to know what kind of CPU and what OS version you are
testing this on.  For example, the JIT in newer platforms may significantly
improve performance here; CPUs that don't have hardware floating point
support may have significantly worse performance.



On Thu, Apr 14, 2011 at 9:17 AM, Paul<pmmen...@gmail.com>  wrote:
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 source data changes? Do you reuse it later? If so and
source
data changes not too often, cache it (write down processed data for
further
reuse). If changes more frequently does it change totally or just is
small
portion? If the latter, process only what's new. And cache it again.
Regards,
Marcin Orlowski
*Tray Agenda<http://bit.ly/trayagenda>* - keep you daily schedule
handy...
*Date In Tray*<http://bit.ly/dateintraypro>  - current date at glance...
WebnetMobile on *Facebook<http://webnetmobile.com/fb/>* and
*Twitter<http://webnetmobile.com/twitter/>
*
--
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 group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.


--
Kostya Vasilyev -- http://kmansoft.wordpress.com

--
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 group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to