Micro -> multiplied under load so the cost accumulates. And here attached is a picture of the memory profile, I am not sure if I read this right, but it says 6-8 Mb.
** Martin 2009/2/9 Igor Vaynberg <[email protected]>: > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
