Hi Richard,
1. Scala traits are something useful which I hope to have someday in Java too.
They can help in make some code reusable when it is not possible to
have common base class. At the end a trait is a partial base class...
2. I'm not sure what problem you are after with this optimization
Martin,
I understand that some on the Wicket mailing list do not
believe that memory usage should be a big concern while others
are very concerned about it. One simply has to look at the
data storage code in the Component class and its complexity
to see a reflection of that concern.
For me,
On Wed, Jul 20, 2011 at 9:00 AM, richard emberson
richard.ember...@gmail.com wrote:
I have many examples of such Java bloat. Consider the getKey method
in the org/apache/wicket/util/value/ValueMap.java class:
Java version:
public String getKey(final String key)
{
for (Object keyValue
Hi Richard,
With the serialization optimizations you optimize only the second and
third level stores, i.e. the runtime memory is still the almost same.
You'll gain only if you have bigger second level cache which is used
when the user uses browser back button. And I think this is no so
often.
Thanks Igor.
it is not allowed, see page#componentRendered()
Thanks.
sharing component instances between pages
I am going to have to think about all of this.
Maybe making mutable and immutable version of things
or, maybe, an Immutable trait (interface) that signals
intent (but, of course,
On Wed, Jul 20, 2011 at 10:19 AM, richard emberson
richard.ember...@gmail.com wrote:
Thanks Igor.
it is not allowed, see page#componentRendered()
Thanks.
sharing component instances between pages
I am going to have to think about all of this.
Maybe making mutable and immutable version of
lol, so scala has a built in isOneOf, of course it wins there...this
is of course a non-example. im not sure why some of our code is so
bloated, its been there for years. i cleaned this one up to, here is
the concise version:
private boolean isOneOf(final char ch, final char[] charray) {
On 07/20/2011 10:03 AM, Martin Grigorov wrote:
Hi Richard,
With the serialization optimizations you optimize only the second and
third level stores, i.e. the runtime memory is still the almost same.
You'll gain only if you have bigger second level cache which is used
when the user uses
Martin,
The reason I was interested in Wicket memory usage was because
of the potential use of Scala traits, rather than the two possible
Java approaches, might be compelling when it comes to memory usage.
First, the two Java approaches: proxy/wrapper object or bundle everything
into the base
Running the third method (the 'problematic' one) 1 times shows no
changes in the PermGen space in VisualVM graphics.
The value is stable at 7.9Mb.
MemoryMXBean shows that non-heap space increases more than heap space
but I didn't find any resource explaining what is included in this
non-heap
When you say 1 times, you set NOS_TIMES to 1?
(NOS_TIMES should have been called ARRAY_SIZE).
Richard
On 07/11/2011 05:38 AM, Martin Grigorov wrote:
Running the third method (the 'problematic' one) 1 times shows no
changes in the PermGen space in VisualVM graphics.
The value is
On Mon, Jul 11, 2011 at 5:12 PM, richard emberson
richard.ember...@gmail.com wrote:
When you say 1 times, you set NOS_TIMES to 1?
I mean NOS_TRIALS.
(NOS_TIMES should have been called ARRAY_SIZE).
Richard
On 07/11/2011 05:38 AM, Martin Grigorov wrote:
Running the third method (the
Hi,
About the use cases: my experience is that most of the time the uses
the in-memory pages (for each listener callback execution, for ajax
requests,...).
Previous version of a page, or previous page is needed when the user
clicks browser back button. Even in this case most of the time the
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
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
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
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
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
18 matches
Mail list logo
