From: Adam Heath <[email protected]>
Subject: Re: Discussion: FlexibleStringExpander refactor
To: [email protected]
Date: Thursday, January 28, 2010, 4:39 PM
Adrian Crum wrote:
Adam Heath wrote:
Adrian Crum wrote:
Adam Heath wrote:
Adrian Crum wrote:
When I refactored
FlexibleStringExpander.java a while ago (rev
687442),
there were things I wanted to improve
but couldn't - because I
wanted to
maintain backward-compatibility.
Adam's recent memory-saving efforts
reminded me of one of the things I
wanted to change in
FlexibleStringExpander.java - I wanted to make the
object more lightweight.
OFBiz can hold anywhere from tens of
thousands to hundreds of
thousands
of these objects in memory, so an
object size reduction could be
beneficial.
With that under consideration, I would
like to do a little more
work on
the class. What I have in mind is to
keep the existing API the same
- to
preserve backward compatibility - but
add an interface so that we can
make gradual changes to framework code
that will improve memory use.
Er, no. Rewrites for the sole
purpose of reducing memory are bad.
Try to profile ofbiz first. All the
stuff I recently did was the
direct outcome of inspecting memory
dumps.
So those rewrites were NOT for the sole
purpose of reducing memory?
Er, I mean to say that don't just assume that you
need to rewwrite it.
I'm looking at the memory usage in heap analyzer
right now.
I never assume. I evaluated it back when I did the
original refactor -
which was done, by the way, for the sole purpose of
reducing memory use.
Well, I just ran trunk, went straight to webtools, artifact
info(got
an exception), then dumped the heap with jmap, and looked
at the file
with heap analyzer. I see 4749 instances in FSE's
cache. All the
instances together take up only 426k of memory.
That's not a whole
lot, considering that the total heap size of this dump is
200M.
