Re: Memory Management
Re: Memory Management
- Subject: Re: Memory Management
- From: Chuck Hill <email@hidden>
- Date: Mon, 2 Mar 2009 22:15:48 -0800
On Mar 2, 2009, at 9:47 PM, Jeff Schmitz wrote:
Actually neither way is working well (reset or dispose). It runs
very fast at first, but then slows down considerably after a couple
of minutes. I noticed that at first Java and Frontbase are both
running with equal percentage of CPU more or less, but then it slows
down and Java takes almost all the CPU. Garbage Collection?
Yes, it sounds like memory starvation. Increase the heap size.
Search the Wiki for how.
Chuck
On Mar 2, 2009, at 1:52 PM, Chuck Hill wrote:
On Mar 1, 2009, at 7:06 PM, Jeff Schmitz wrote:
On Feb 24, 2009, at 12:22 PM, Chuck Hill wrote:
On Feb 23, 2009, at 9:13 PM, Jeff Schmitz wrote:
Hello,
In my app I frequently need to run operations that read in
nearly all the data in my database. One I run in the foreground
(I have concurrent request handling on), and another I run in
the background with its own EOObjectStoreCoordinator. If I
understand how things work (and there's no guarantee of that),
that would mean I basically have 4 copies of my database in
memory at once (2 ECs and to object stores).
No. :-) Two copies. The objects in the EC don't copy the data,
they only have references to the data in the object store. If
you change an EO, only the changed values are stored in the EC,
and only until it is saved.
Then I think there must be a LOT of references that build up.
When I changed my code to reset the ec periodically (after each
pool processed) it made a HUGE difference. Before that, my
development machine would eventually come to a grinding halt.
After the change it ran through everything with no noticeable
slowdown. e.g.
while (nameIter.hasNext()) {
poolName = nameIter.next();
Pool pool = Pool.fetchStandardPoolWithName(ec, poolName);
pool.doLongLastingCalcs();
ec.reset();
}
was MUCH better than:
NSArray<Pool> pools = Pool.fetchStandardPoolsByName(ec);
Iterator<Pool> poolIter = pools.iterator();
while (poolIter.hasNext()) {
pool = poolIter.next();
pool.doLongLastingCalcs();
}
Would unlock and dispose and creating a new EC in each loop be
better than ec.reset()?
Try it and see. If you don't do something then the undostack
builds up. You also need to ensure that your code does not keep
references to objects in the EC.
Chuck
As I use the data in a serial fashion, I was wondering if
there's a way to release the EOs that are held in memory in both
the EC and the Object Store once I know my each process is
through with them, especially for the threaded process that has
its own object store? Is just using ec.reset() at key points
the way to go for the ec's? What about for the object stores?
http://wiki.objectstyle.org/confluence/display/WO/EOF-Using+EOF-Memory+Management
Your best bet (IMO) is to unlock and dispose of the EC and then
create a new one and carry on. Look after the editing contexts,
and the object stores will take care of themselves.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden