is that 291 milliseconds or 291 microseconds? -igor
On Sun, Feb 8, 2009 at 7:46 PM, Martin Makundi <[email protected]> wrote: > I remembered it was a hotspot. Checking again, it is not a memory > bottleneck but a performance bottleneck. I apologise for my > imprecision. > > I have several BigDecimalLabels each with its own converter. Each > instance creation takes 291 us on the reference computer. Furthermore, > each of the getNumberFormat -call takes 215 us each. > > This seems insignificant at first, but in load tests it becomes > significant (top-2 and top-3 hoggers). > > Two suggestions: > 1. > I wonder if, instead of cloning the NumberFormats for every use, a > lazy threadlocal copy should be used instead? > > 2. > Another thing that came into my mind is, that there is > newNumberFormat(Locale locale) -method in AbstractDecimalConverter, > but the method is never used [instead, there is a direct "numberFormat > = NumberFormat.getInstance(locale);" -invocation in > getNumberFormat(Locale locale)]. > > Is this not a bug? > > I would like to override the newNumberFormat method (if it was ever > actually used) in my own XXConverter, in order to parametrize it for > my specific style. > > ::: > > As what comes to the > org.apache.wicket.Component#getConverter(java.lang.Class), I guess I > will have to implement my own TunedConverterLocator that can > orchestrate the desired converer variants for each type. > > ** > Martin > > 2009/2/8 Jeremy Thomerson <[email protected]>: >> What in particular was hogging that 200MB of memory? Was your converter >> holding something? If it were just a simple converter class like most, it >> would take thousands upon thousands of them to take that much memory. Most >> likely, you have another issue. Run a profiler and let us know what's using >> the memory. >> >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> On Sun, Feb 8, 2009 at 2:26 PM, Martin Makundi < >> [email protected]> wrote: >> >>> Exactly. I had a component with its own converter and my memory >>> profiler showed that it ended up hogging 200 MB. >>> >>> Ofcourse I can organize my own singleton library of converters.. but >>> Wicket has its own ConverterLocator. I would like to hear if someone >>> has made such an implementation of ConverterLocator that you can have >>> 'tuned' converters - instead of just one converter per type. >>> >>> ** >>> Martin >>> >>> >>> 2009/2/8 Thomas Mäder <[email protected]>: >>> > You can override getConverter() on a component to return any converter >>> you >>> > want. >>> > >>> > Thomas >>> > >>> > On Sun, Feb 8, 2009 at 6:53 PM, Martin Makundi < >>> > [email protected]> wrote: >>> > >>> >> Hi! >>> >> >>> >> I am a bit confused with the converters in Wicket. I have some numbers >>> >> which I want to display with two decimals and some other numbers with >>> >> another amout of decimals. >>> >> >>> >> It appears like Wicket has only one instance of BigDecimalConverter, >>> >> which is used everywhere. So if I adjust its NumberFormat, the effect >>> >> will be seen everywhere. Is this true? >>> >> >>> >> Who knows of an flexible but elegant way to work with the Wicket >>> >> converters? Creating new converters for each label or textfield >>> >> results in a lot of garbage in the memory footprint... >>> >> >>> >> ** >>> >> Martin >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >> >>> > >>> > >>> > -- >>> > Thomas Mäder >>> > Wicket & Eclipse Consulting >>> > www.devotek-it.ch >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
