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 <mailto: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
