You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jacob Hookom <ho...@uwec.edu> on 2002/11/01 05:51:32 UTC
[OT] Memory Footprint of DynaX vs. BO
By implementation, I'm assuming that DynaX uses an underlying Map to store properties. I'm wondering how using a Map to store attribute data differs from storing the same data in BO's along the lines of memory consumption?
Regards,
Jacob Hookom
Re: [OT] Memory Footprint of DynaX vs. BO
Posted by Jacob Hookom <ho...@uwec.edu>.
Heheh, I'm putting this one in my 'save' bin :-)
----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Saturday, November 02, 2002 11:06 AM
Subject: Re: [OT] Memory Footprint of DynaX vs. BO
> Craig R. McClanahan wrote:
> >
> > On Thu, 31 Oct 2002, Jacob Hookom wrote:
> >
> >
> >>Date: Thu, 31 Oct 2002 22:51:32 -0600
> >>From: Jacob Hookom <ho...@uwec.edu>
> >>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> >>To: Struts Users Mailing List <st...@jakarta.apache.org>
> >>Subject: [OT] Memory Footprint of DynaX vs. BO
> >>
> >>By implementation, I'm assuming that DynaX uses an underlying Map to
> >>store properties. I'm wondering how using a Map to store attribute data
> >>differs from storing the same data in BO's along the lines of memory
> >>consumption?
> >>
> >
> >
> > In Struts, DynaActionForm does indeed store its property values in a
Map,
> > which makes the memory occupancy pretty similar to using Maps directly,
> > and are a little larger than using JavaBeans with properties (though not
a
> > lot, because there's a few bytes of overhead per bean instance as well).
> >
> > My personal advice, though, is to not stress over this kind of detail
> > unless you're building an incredibly high-transaction-rate app. Use the
> > development technique that takes you the least amount of time -- and use
> > the time you save to tune your database queries instead. You'll get
> > orders of magnitude more impact on improving response time doing this
than
> > you would saving a few bytes of temporary memory occupancy here and
there.
>
> Yes, I agree strongly with Craig -- and even in high-transaction-rate
> apps, while reducing memory footprint can "help" you, not spending
> enough time ensuring throughput can "kill" you.
>
> Think of the front end of your web app as a "request parking lot". If
> you can get the customers in and out of your store more or less as fast
> as they arrive, it doesn't matter all that much whether they are driving
> SUVs or compact cars -- they will be able to find parking. Once things
> start to back up, however, you are going to start losing customers,
> regardless of what they're driving or how large a parking lot you have.
> You certainly want to avoid ridiculous situations where each customer
> brings in a line of mobile homes; but assuming that you have done that,
> you're better off making sure that you have enough cashiers and they
> move fast enough than trying to get all your customers to drive
> compacts. :-)
>
> I don't mean to suggest that optimizing memory management is not an
> important element in performance tuning high-volume applications. It
> certainly is. The point is that assuming best practices (e.g. efficient
> use of the framework and container, minimal server-side state, etc.)
> have been followed in design, it is generally best to focus first on
> optimizing throughput, IMHO.
>
> Regards,
>
> Phil Steitz
>
>
> >
> > You can always go back later and tune things up if this does turn out to
> > matter. (Or just spend a couple hundred bucks on some more memory ...).
> >
> >
> >>Regards,
> >>Jacob Hookom
> >
> >
> > Craig
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Memory Footprint of DynaX vs. BO
Posted by Phil Steitz <ph...@steitz.com>.
Craig R. McClanahan wrote:
>
> On Thu, 31 Oct 2002, Jacob Hookom wrote:
>
>
>>Date: Thu, 31 Oct 2002 22:51:32 -0600
>>From: Jacob Hookom <ho...@uwec.edu>
>>Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
>>To: Struts Users Mailing List <st...@jakarta.apache.org>
>>Subject: [OT] Memory Footprint of DynaX vs. BO
>>
>>By implementation, I'm assuming that DynaX uses an underlying Map to
>>store properties. I'm wondering how using a Map to store attribute data
>>differs from storing the same data in BO's along the lines of memory
>>consumption?
>>
>
>
> In Struts, DynaActionForm does indeed store its property values in a Map,
> which makes the memory occupancy pretty similar to using Maps directly,
> and are a little larger than using JavaBeans with properties (though not a
> lot, because there's a few bytes of overhead per bean instance as well).
>
> My personal advice, though, is to not stress over this kind of detail
> unless you're building an incredibly high-transaction-rate app. Use the
> development technique that takes you the least amount of time -- and use
> the time you save to tune your database queries instead. You'll get
> orders of magnitude more impact on improving response time doing this than
> you would saving a few bytes of temporary memory occupancy here and there.
Yes, I agree strongly with Craig -- and even in high-transaction-rate
apps, while reducing memory footprint can "help" you, not spending
enough time ensuring throughput can "kill" you.
Think of the front end of your web app as a "request parking lot". If
you can get the customers in and out of your store more or less as fast
as they arrive, it doesn't matter all that much whether they are driving
SUVs or compact cars -- they will be able to find parking. Once things
start to back up, however, you are going to start losing customers,
regardless of what they're driving or how large a parking lot you have.
You certainly want to avoid ridiculous situations where each customer
brings in a line of mobile homes; but assuming that you have done that,
you're better off making sure that you have enough cashiers and they
move fast enough than trying to get all your customers to drive
compacts. :-)
I don't mean to suggest that optimizing memory management is not an
important element in performance tuning high-volume applications. It
certainly is. The point is that assuming best practices (e.g. efficient
use of the framework and container, minimal server-side state, etc.)
have been followed in design, it is generally best to focus first on
optimizing throughput, IMHO.
Regards,
Phil Steitz
>
> You can always go back later and tune things up if this does turn out to
> matter. (Or just spend a couple hundred bucks on some more memory ...).
>
>
>>Regards,
>>Jacob Hookom
>
>
> Craig
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Memory Footprint of DynaX vs. BO
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 31 Oct 2002, Jacob Hookom wrote:
> Date: Thu, 31 Oct 2002 22:51:32 -0600
> From: Jacob Hookom <ho...@uwec.edu>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: [OT] Memory Footprint of DynaX vs. BO
>
> By implementation, I'm assuming that DynaX uses an underlying Map to
> store properties. I'm wondering how using a Map to store attribute data
> differs from storing the same data in BO's along the lines of memory
> consumption?
>
In Struts, DynaActionForm does indeed store its property values in a Map,
which makes the memory occupancy pretty similar to using Maps directly,
and are a little larger than using JavaBeans with properties (though not a
lot, because there's a few bytes of overhead per bean instance as well).
My personal advice, though, is to not stress over this kind of detail
unless you're building an incredibly high-transaction-rate app. Use the
development technique that takes you the least amount of time -- and use
the time you save to tune your database queries instead. You'll get
orders of magnitude more impact on improving response time doing this than
you would saving a few bytes of temporary memory occupancy here and there.
You can always go back later and tune things up if this does turn out to
matter. (Or just spend a couple hundred bucks on some more memory ...).
> Regards,
> Jacob Hookom
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>