Re: Panel as instance variable of parent ?
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 Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Panel as instance variable of parent ?
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 ) 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:54768690858392 [Ljava.util.HashMap$Entry; 4:11530370210936 [B 5:60156755782288 [Ljava.lang.Object; 6: 121803548721400 java.lang.String 7:12519644284696 [I 8:61725234566112 org.apache.wicket.markup.html.basic.Label 9:51388532888640 java.util.HashMap 10:15476127478104 11: 2073924243264 12:64087021669424 [Ljava.lang.String; 13:15476118585784 14:45779818311920 java.sql.Timestamp 15:75389218093408 java.lang.Long 16:13819517688960 com.foo.entities.Foo 17: 2073916699448 18: 1902915086496 19:16719214712896 org.hibernate.collection.PersistentSet 20:17998814399040 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Panel as instance variable of parent ?
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 ) 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:54768690858392 [Ljava.util.HashMap$Entry; 4:11530370210936 [B 5:60156755782288 [Ljava.lang.Object; 6: 121803548721400 java.lang.String 7:12519644284696 [I 8:61725234566112 org.apache.wicket.markup.html.basic.Label 9:51388532888640 java.util.HashMap 10:15476127478104 11: 2073924243264 12:64087021669424 [Ljava.lang.String; 13:15476118585784 14:45779818311920 java.sql.Timestamp 15:75389218093408 java.lang.Long 16:13819517688960 com.foo.entities.Foo 17: 2073916699448 18: 1902915086496 19:16719214712896 org.hibernate.collection.PersistentSet 20:17998814399040 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
