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]

Reply via email to