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 <[email protected]> wrote:
> 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<[email protected]>  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<[email protected]>  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<[email protected]>  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 [email protected]
> >>> To unsubscribe from this group, send email to
> >>> [email protected]
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/android-developers?hl=en
> >> --
> >> Dianne Hackborn
> >> Android framework engineer
> >> [email protected]
>
> >> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to