that means you can create about 3500/second...how many users do you have on that server? can you show us the timing screenshot, i am very curious. btw, your memory profile attachment didnt make it through, maybe you can upload your images somewhere else.
-igor On Sun, Feb 8, 2009 at 8:09 PM, Martin Makundi <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
