Re: Model performance question
The wiki says (https://cwiki.apache.org/WICKET/working-with-wicket-models.html):
"Compound models allow containers to share models with their children.
This saves memory, but more importantly, it makes replication of
models much cheaper in a clustered environment."
I think what we're saying in this thread is that PropertyModels
actually have the same benefits as CPM; that is, a CPM doesn't give
you any performance benefits over using a PropertyModel -- there's
less typing with a CPM, but it ends up the same in the end. Does that
sound right?
Andrew
On Tue, Jun 25, 2013 at 12:02 PM, Bas Gooren wrote:
> Hi,
>
> It sounds like you know what you are doing, but I just want to check why you
> chose "myObject" as a variable name in your example?
> If you are properly using detachable models and do not want to serialize a
> large object graph, "myObject" needs to be a loadable detachable model, and
> not an actual object in your example.
> "myLDM" or "myObjectModel" would be a more logical name.
>
> In my experience it doesn't matter where you create your models, because
> using a compound property model will automatically create propertymodels on
> your nested components anyway. Each component needs its own model anyway, to
> get and set its value.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 25-6-2013 16:20, schreef gmparker2000:
>
>> Considering two alternative ways to set a model:
>>
>> ...
>> final CompoundPropertyModel myModel = new
>> CompoundPropertyModel(myObject);
>>
>> control1.setModel(myModel.bind("field1"));
>> control2.setModel(myModel.bind("field2"));
>> control3.setModel(myModel.bind("field3"));
>> ...
>>
>> and
>> ...
>> control1.setModel(new PropertyModel(myObject, "field1));
>> control2.setModel(new PropertyModel(myObject, "field2));
>> control3.setModel(new PropertyModel(myObject, "field3));
>> ...
>>
>> are there any performance benefits of one over the other? I profiled each
>> and they appear equivalent from the number of objects created point of
>> view.
>> I just want to make sure that option two isn't doing something like
>> serializing "myObject" for each control. It doesn't appear that this is
>> happening but wanted to make sure.
>>
>> We are binding controls to fairly large nested Java Objects. Other than
>> making sure to use LoadableDetachable models where possible are there any
>> other strategies for making sure performance is optimal? For example,
>> would
>> setting the model on the form rather than on each control have any
>> performance benefit?
>>
>> Thanks
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Model-performance-question-tp4659771.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> 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
Re: Model performance question
Hi,
It sounds like you know what you are doing, but I just want to check why
you chose "myObject" as a variable name in your example?
If you are properly using detachable models and do not want to serialize
a large object graph, "myObject" needs to be a loadable detachable
model, and not an actual object in your example.
"myLDM" or "myObjectModel" would be a more logical name.
In my experience it doesn't matter where you create your models, because
using a compound property model will automatically create propertymodels
on your nested components anyway. Each component needs its own model
anyway, to get and set its value.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 25-6-2013 16:20, schreef gmparker2000:
Considering two alternative ways to set a model:
...
final CompoundPropertyModel myModel = new
CompoundPropertyModel(myObject);
control1.setModel(myModel.bind("field1"));
control2.setModel(myModel.bind("field2"));
control3.setModel(myModel.bind("field3"));
...
and
...
control1.setModel(new PropertyModel(myObject, "field1));
control2.setModel(new PropertyModel(myObject, "field2));
control3.setModel(new PropertyModel(myObject, "field3));
...
are there any performance benefits of one over the other? I profiled each
and they appear equivalent from the number of objects created point of view.
I just want to make sure that option two isn't doing something like
serializing "myObject" for each control. It doesn't appear that this is
happening but wanted to make sure.
We are binding controls to fairly large nested Java Objects. Other than
making sure to use LoadableDetachable models where possible are there any
other strategies for making sure performance is optimal? For example, would
setting the model on the form rather than on each control have any
performance benefit?
Thanks
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Model-performance-question-tp4659771.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Model performance question
Hi,
On Tue, Jun 25, 2013 at 5:20 PM, gmparker2000 wrote:
> Considering two alternative ways to set a model:
>
> ...
> final CompoundPropertyModel myModel = new
> CompoundPropertyModel(myObject);
>
> control1.setModel(myModel.bind("field1"));
> control2.setModel(myModel.bind("field2"));
> control3.setModel(myModel.bind("field3"));
> ...
>
> and
> ...
> control1.setModel(new PropertyModel(myObject, "field1));
> control2.setModel(new PropertyModel(myObject, "field2));
> control3.setModel(new PropertyModel(myObject, "field3));
> ...
>
> are there any performance benefits of one over the other? I profiled each
> and they appear equivalent from the number of objects created point of
> view.
> I just want to make sure that option two isn't doing something like
> serializing "myObject" for each control. It doesn't appear that this is
> happening but wanted to make sure.
>
Java serialization writes a given instance just once and all following
writes of the same instance will write just pointers to the first write
>
> We are binding controls to fairly large nested Java Objects. Other than
> making sure to use LoadableDetachable models where possible are there any
> other strategies for making sure performance is optimal? For example,
> would
> setting the model on the form rather than on each control have any
> performance benefit?
>
> Thanks
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Model-performance-question-tp4659771.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Model performance question
Considering two alternative ways to set a model:
...
final CompoundPropertyModel myModel = new
CompoundPropertyModel(myObject);
control1.setModel(myModel.bind("field1"));
control2.setModel(myModel.bind("field2"));
control3.setModel(myModel.bind("field3"));
...
and
...
control1.setModel(new PropertyModel(myObject, "field1));
control2.setModel(new PropertyModel(myObject, "field2));
control3.setModel(new PropertyModel(myObject, "field3));
...
are there any performance benefits of one over the other? I profiled each
and they appear equivalent from the number of objects created point of view.
I just want to make sure that option two isn't doing something like
serializing "myObject" for each control. It doesn't appear that this is
happening but wanted to make sure.
We are binding controls to fairly large nested Java Objects. Other than
making sure to use LoadableDetachable models where possible are there any
other strategies for making sure performance is optimal? For example, would
setting the model on the form rather than on each control have any
performance benefit?
Thanks
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Model-performance-question-tp4659771.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
