no, but it should take out that Task$1 which is the biggest cpu hog. -igor
On Sun, Feb 8, 2009 at 9:25 PM, Martin Makundi <[email protected]> wrote: >> are you load testing wicket in development mode? > > Ofcourse ;) > > I run the tests again in deployment mode, does not affect the > BigDecimalConverter results. > > ** > Martin > >> >> On Sun, Feb 8, 2009 at 8:32 PM, Martin Makundi >> <[email protected]> wrote: >>>> that means you can create about 3500/second...how many users do you >>>> have on that server? >>> >>> It's just a load test. It's a heavyish page on itself and I am hitting >>> it with about 20 concurrent users. >>> >>>> btw, your memory profile attachment didnt make it through, >>>> maybe you can upload your images somewhere else. >>> >>> Yeah, I noticed. Here: http://s5.tinypic.com/2igki7k.jpg >>> >>> Note, the allocation count is wild. It is inconsistent with the >>> invocation count: >>> >>>> can you show us the timing screenshot, i am very curious. >>> >>> Here: http://s5.tinypic.com/2yoviuf.jpg >>> >>> I am curious about the bug I mentioned in suggestion 2), it appears >>> like a blatant oversight bug, don't you think? >>> >>> ** >>> Martin >>> >>>> 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] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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]
