> 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]

Reply via email to