string literals are interned by the jvm so they should have a minimal memory impact.
-igor On Sat, Jul 9, 2011 at 5:10 PM, richard emberson <richard.ember...@gmail.com> wrote: > Martin, > > The reason I was interested was because it struck me a couple of > days ago that while each Page, tree of Components, is created > many (almost all?) of the non-end-user-generated Strings stored > as instance variables in the tree are shared > between all copies of the Page but that when such a Page is > serialized to disk and then de-serialized, each String becomes its own > copy unique to that particular Page. This means that if an > appreciable number of Pages in-memory are reanimated Pages, then > there could be a bunch of memory being used for all the String > copies. > > In the attached simple Java file (yes, I still write Java when I must) > there are three different ways of creating an array of > Label objects (not Wicket Label) where each Label takes a String: > new Label(some_string) > > The first is to share the same String over all instance of the Label. > new Label(the_string) > The second is to make a copy of the String when creating each > Label; > new Label(new String(the_string)) > The third is to create a single Label, serialize it to an array of > bytes and then generate the Labels in the array by de-serialized > the byte array for each Label. > > Needless to say, the first uses the least memory; the label string > is shared by all Labels while the second and third approach > uses more memory. Also, if during the de-serialization process, the > de-serialized String is replaced with the original instance of the > String, then the third approach uses only as much memory as the > first approach. > > No rocket science here, but it does seem to imply that if a > significant number of Pages in-memory are actually reanimated Pages, > then there could be a memory saving by > making de-serialization smarter about possible shared objects. > Even it it is only, say, a 5% saving for only certain Wicket > usage patterns, it might be worth looking into. > > Hence, my question to the masters of Wicket and developers whose > application might fit the use-case. > > Richard > > On 07/09/2011 11:03 AM, Martin Makundi wrote: >> >> Difficult to say ... we have disabled page versioning and se dump >> sessions onto disk every 5 minutes to minimize memory hassles. >> >> But I am no master ;) >> >> ** >> Martin >> >> 2011/7/9 richard emberson<richard.ember...@gmail.com>: >>> >>> This is a question for Wicket masters and those application builders >>> whose application match the criteria as specified below. >>> >>> [In this case, a Wicket master is someone with a knowledge >>> of how Wicket is being used in a wide spectrum of applications >>> so that they have a feel for what use-cases exist in the real world.] >>> >>> Wicket is used in a wide range of applications with a variety of >>> usage patterns. What I am interested in are those applications where >>> an appreciable number of the pages in memory are pages that had >>> previously been serialized and stored to disk and then reanimated, >>> not found in an in-memory cache and had to be read from disk and >>> de-serialized back into an in-memory page; which is to say, >>> applications with an appreciable number of reanimated pages. >>> >>> Firstly, do such applications exists? These are real-world >>> applications where a significant number of pages in-memory >>> are reanimated pages. >>> >>> For such applications, what percentage of all pages at any >>> given time are reanimated pages? >>> Is it, say, a couple of percent? Two or three in which case its not >>> very significant. >>> Or, is it, say, 50%? Meaning that half of all pages currently in >>> memory had been serialized to disk, flushed from any in-memory cache >>> and then, as needed, de-serialized back into a Page. >>> >>> Thanks >>> >>> Richard >>> -- >>> Quis custodiet ipsos custodes >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > -- > Quis custodiet ipsos custodes > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
