You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thies Edeling <th...@rrm.net> on 2008/11/24 15:03:34 UTC
Panel as instance variable of parent ?
Hi all,
I was wondering what the best aproach is, memory-wise, to reference a
panel from it's parent (or other compent). Either keep a reference to a
panel as an instance variable in it's parent or look it up in the
hierarchy using get(path). The look up in the hierarchy is more brittle
but I'm not entirely sure what the memory impact (if any) is of storing
it as an instance var.
thx
Thies
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Panel as instance variable of parent ?
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Mon, 24 Nov 2008, Thies Edeling wrote:
> I was wondering what the best aproach is, memory-wise, to reference a
> panel from it's parent (or other compent). Either keep a reference to a
> panel as an instance variable in it's parent or look it up in the
> hierarchy using get(path). The look up in the hierarchy is more brittle
> but I'm not entirely sure what the memory impact (if any) is of storing
> it as an instance var.
The problem is not the memory usage but coupling, which
should be reduced by using Component.visitChildren() instead
of get(path).
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Panel as instance variable of parent ?
Posted by Thies Edeling <th...@rrm.net>.
Thanks! I was more worried about preventing garbage collection etc.
But I guess that when a component is loaded in memory all of it's
children should be as well so any reference is valid.
Martijn Dashorst wrote:
> unless you have a clear indication that keeping the reference is
> causing you pain, I should not worry about it. A reference takes up 4
> bytes iirc, so if you have 1024 of them in your app instance, that
> will take a 4kb hit. Now that is nothing to worry about.
>
> Here's a histogram snapshot (jmap -histo <pid>) of memory usage of one
> of our production boxes:
>
> num #instances #bytes class name
> --------------------------------------
> 1: 1013497 268442672 [C
> 2: 3430701 164673648 java.util.HashMap$Entry
> 3: 547686 90858392 [Ljava.util.HashMap$Entry;
> 4: 115303 70210936 [B
> 5: 601567 55782288 [Ljava.lang.Object;
> 6: 1218035 48721400 java.lang.String
> 7: 125196 44284696 [I
> 8: 617252 34566112 org.apache.wicket.markup.html.basic.Label
> 9: 513885 32888640 java.util.HashMap
> 10: 154761 27478104 <constMethodKlass>
> 11: 20739 24243264 <constantPoolKlass>
> 12: 640870 21669424 [Ljava.lang.String;
> 13: 154761 18585784 <methodKlass>
> 14: 457798 18311920 java.sql.Timestamp
> 15: 753892 18093408 java.lang.Long
> 16: 138195 17688960 com.foo.entities.Foo
> 17: 20739 16699448 <instanceKlassKlass>
> 18: 19029 15086496 <constantPoolCacheKlass>
> 19: 167192 14712896 org.hibernate.collection.PersistentSet
> 20: 179988 14399040 org.hibernate.collection.PersistentBag
>
> As you can see: the top 20 doesn't contain that many components from
> Wicket (most is caching related to hibernate), this also explains why
> we are very conservative of adding new flags to the core Wicket
> components: these are typically used many, many times, but your own
> custom components not as much.
>
> Our first custom component is #48 with 32404 instances and 2592320
> bytes of memory (80 bytes per instance shallow depth). Adding an
> additional reference would've increased the memory usage by 128kb
> which is peanuts.
>
> Martijn
>
> On Mon, Nov 24, 2008 at 3:03 PM, Thies Edeling <th...@rrm.net> wrote:
>
>> Hi all,
>>
>> I was wondering what the best aproach is, memory-wise, to reference a panel
>> from it's parent (or other compent). Either keep a reference to a panel as
>> an instance variable in it's parent or look it up in the hierarchy using
>> get(path). The look up in the hierarchy is more brittle but I'm not entirely
>> sure what the memory impact (if any) is of storing it as an instance var.
>>
>> thx
>> Thies
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Panel as instance variable of parent ?
Posted by Martijn Dashorst <ma...@gmail.com>.
unless you have a clear indication that keeping the reference is
causing you pain, I should not worry about it. A reference takes up 4
bytes iirc, so if you have 1024 of them in your app instance, that
will take a 4kb hit. Now that is nothing to worry about.
Here's a histogram snapshot (jmap -histo <pid>) of memory usage of one
of our production boxes:
num #instances #bytes class name
--------------------------------------
1: 1013497 268442672 [C
2: 3430701 164673648 java.util.HashMap$Entry
3: 547686 90858392 [Ljava.util.HashMap$Entry;
4: 115303 70210936 [B
5: 601567 55782288 [Ljava.lang.Object;
6: 1218035 48721400 java.lang.String
7: 125196 44284696 [I
8: 617252 34566112 org.apache.wicket.markup.html.basic.Label
9: 513885 32888640 java.util.HashMap
10: 154761 27478104 <constMethodKlass>
11: 20739 24243264 <constantPoolKlass>
12: 640870 21669424 [Ljava.lang.String;
13: 154761 18585784 <methodKlass>
14: 457798 18311920 java.sql.Timestamp
15: 753892 18093408 java.lang.Long
16: 138195 17688960 com.foo.entities.Foo
17: 20739 16699448 <instanceKlassKlass>
18: 19029 15086496 <constantPoolCacheKlass>
19: 167192 14712896 org.hibernate.collection.PersistentSet
20: 179988 14399040 org.hibernate.collection.PersistentBag
As you can see: the top 20 doesn't contain that many components from
Wicket (most is caching related to hibernate), this also explains why
we are very conservative of adding new flags to the core Wicket
components: these are typically used many, many times, but your own
custom components not as much.
Our first custom component is #48 with 32404 instances and 2592320
bytes of memory (80 bytes per instance shallow depth). Adding an
additional reference would've increased the memory usage by 128kb
which is peanuts.
Martijn
On Mon, Nov 24, 2008 at 3:03 PM, Thies Edeling <th...@rrm.net> wrote:
> Hi all,
>
> I was wondering what the best aproach is, memory-wise, to reference a panel
> from it's parent (or other compent). Either keep a reference to a panel as
> an instance variable in it's parent or look it up in the hierarchy using
> get(path). The look up in the hierarchy is more brittle but I'm not entirely
> sure what the memory impact (if any) is of storing it as an instance var.
>
> thx
> Thies
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org