Nikolaos,
Well, we'll agree to disagree. No harm in that. I wish you the best in
finding a solution.
-- Rick
On Sun, Jul 4, 2010 at 9:54 PM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:
> Rick,
>
> Comments in-line... .
>
>
>
> Rick Grashel wrote:
>
> Nik,
>
> If you truly want to eliminate unneeded instantiation, then I would promote
> the "created" variable into a first-order entity. Have its fetch type be
> set to lazy.
>
> I honestly don't see how setting fetch type to lazy resolves the issue.
> This is not a complex graph or something that needs to be loaded or
> anything. This is about initialization of a Data / Model Object... I don't
> see how delayed reloading will help... if anything if there are enough small
> objects lazy loaded then this only degrades performance.
>
>
> But I personally think all this is a little overkill. I would say that
> if you are concerned about adding a simple long... you have other problems.
>
> Please read my reply. It's not a simple Long. 100 user log-ins results in
> 600-1200 OBJECTS needlessly getting created. 1000 user logins results in
> 6000-12000 "objects" needlessly getting created. And that is for 1 type of
> object... there are literally 2 dozen other model objects... all but the
> simplest object face this issue i.e. any Data / Model Object that requires
> some sort of implicit initial value has this issue.
>
> Objects in Java that are not referenced are automagically GC'd but that has
> a price in a) unnecessarily consuming more Java Heap than is necessary and
> b) in CPU resources to do so. So NO this is a very real problem in the real
> world. What I gave you was a rudimentary example of it.
>
>
> So following your first instinct, why not do it the simplest way and then
> load test it?
>
> Because that wasn't what I said - I said: "*Some might try to argue* that
> I am trying to prematurely optimize and that is bad, but "unnecessary" and
> moreover in this case pointless object creation should always be avoided in
> any system, as these types of oversights always seem to bite back when in
> Production."
>
>
> If it truly represented a problem, it wouldn't be hard to refactor.
>
> So an analogy of this would be to say - in your home - produce a lot of
> extra garbage not because you have to but just because you can - and then do
> a study to see if you produced a significant amount of garbage. Isn't it
> better to not unnecessarily inflate the amount of garbage you are going to
> produce? It is going to end up somewhere? It may not tip the tide or cause
> an environmental catastrophe but if the unnecessary extra garbage can be
> avoided... wouldn't it be preferable to avoid producing the extra garbage.
>
> Refactor what? Yes that is a wonderful canned answer but I'm not sure you
> clearly understand what I am trying to do here. This is a "general" problem
> in this space and in this age of automagically constructed Data / Model
> objects where in in some cases intialization is required and in other cases
> because the data will be overloaded it is not wanted.
>
> <rant>
> I don't think enough developers have the opportunity to work as system
> admins OR performance tune existing systems... to see the challenges that
> some Java systems have with tons of unnecessary object creation, continuous
> garbage collection, CPU spikes, processes falling over, and horizontally and
> vertically adding servers or upgrading hardware to accommodate until systems
> / software can be re-written... is a very common occurrence.
> </rant>
>
>
> The workarounds you are discussing are bound to make the code ugly and
> not easy to understand or maintain.
>
> Your assumption is that there is no elegant solution to this problem. Just
> because the problem appears difficult to solve does not mean that the code
> will be ugly and not easy to understand or maintain. I don't see the basis
> for such an argument when nothing beyond a trivial solution has been
> explored i.e. the solution of attribute assignment vs. an initialize method
> called automatically from the constructor are pretty much the same.
>
>
> It really sounds like you are trying to solve a problem that may not
> exist at all. Over-optimization is as bad of an anti-pattern as any.
>
> So you "never" have had a case where a Data / Model object requires
> implicit initialization... e.g. a creation time stamp, a score that must
> start at 0, an embedded object, etc... . I guess it is quite entirely
> possible and if so you are correct then I guess there really is no
> problem...
>
> Please read the above and my original post and replies. This is not
> premature over-optimization... this is prudent development... and there is a
> huge difference IMO. Over-optimization is in making an algorithm or an
> architecture far more flexible or robust than it need be... this is about
> building an architecture were I don't have to compensate by tossing in extra
> hardware / servers because the developers didn't have the sense to implement
> with some basic foresight. Algorithms should be well written and that is
> not to be confused with over-optimization.
>
> Cheers,
>
> --Nikolaos
>
>
> -- Rick
>
> On Jul 4, 2010 1:31 PM, "Nikolaos Giannopoulos" <nikol...@brightminds.org>
> wrote:
>
> Rick,
>
> Thanks for the response. That is a great idea "except" that once again it
> results in: Unnecessary object creation and unnecessary garbage collection.
>
> Imagine having say 6-12 of these types of things and logging in say a 100
> users... thats an extra 600-1200 "unnecessary" objects that get created and
> discarded immediately. Now imagine logging in a 1000 users... 6000-12000
> "unnecessary" objects created and discarded.
>
> And in our case it is even worse as we have several Embedded objects in
> each model... so you are "unnecessarily" creating the Embedded object
> wrapper as well e.g. we have a TimestampDetails class that retains "created"
> and "updated" times so even if we init only the "created" then we have 2
> objects getting created there... so the 6-12 objects per model is quite
> "real".
>
> Some might try to argue that I am trying to prematurely optimize and that
> is bad but "unnecessary" and moreover in this case pointless object creation
> should always be avoided in any system as these types of oversights always
> seem to bite back when in Production.
>
> Any other ideas? Thoughts???
>
> --Nikolaos
>
>
>
> Rick Grashel wrote:
> >
> > Nikolaos,
> >
> > Why not simply initialize the variable in the User class ...
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
