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 <[email protected]> wrote: > 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 results as I have them! > > Paul > > On Apr 14, 4:26 pm, Dianne Hackborn <[email protected]> wrote: > > > 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 implementation, it is probably way > > over-engineered and inefficient. :) If your numbers are normally of the > > form "xxxxx.yyy" you could try writing your own parser that parses that form > > as efficiently as possible, and bail to the generic impl if it finds > > something it can't handle. > > > You certainly should be able to write something that doesn't have a $#&^%!! > > StringBuilder involved (good ghod!). > > > On Thu, Apr 14, 2011 at 11:43 AM, Paul <[email protected]> wrote: > > > 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 > > > -- > > 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
