I you run the little Java program I included, you will see that
there is an impact - de-serialized objects take more memory.
Richard
On 07/09/2011 05:23 PM, Igor Vaynberg wrote:
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
--
Quis custodiet ipsos custodes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
