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. -- 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
