Re: real verses Virtual memory
Re: real verses Virtual memory
- Subject: Re: real verses Virtual memory
- From: Michael Dautermann <email@hidden>
- Date: Sat, 10 Oct 2009 08:44:37 -0700
On Oct 10, 2009, at 8:24 AM, jon wrote:
it loads a website, to see if there are changes to the website, it
then does a lot of work, the large memory things, like the
"webView" are just one instance, and are not deallocating... (uses
just that one instance over and over again, not making new ones)
so that i don't think is the problem... (or maybe even if the
instance is allocated just once, does reloading a webView do any
thing that makes it write to memory?)
and then all the little stuff of allocating for a small variable,
is adding up each time, i really don't want to make every variable
global... but if that is proper technique, then i'll do that...
are we saying there is no way to make a process use real memory?
I don't know the answer to that last question off the top of my head.
It sounds like you're using a repeatedly polling process with a
potentially large footprint. No wonder you're seeing the disk
thrashing you are.
Is this a website that you have control over? Where if anything
changes, you could have a notification sent to the application to do
the work it needs to do (so you could avoid all that crazy polling
that you're doing)?
Could you lengthen the time between polls safely? 30 minutes between
polls might be nicer on a machine than 20 seconds and you'd still
catch your content updates.
Does the remote site have lots of resources that you have to check
(i.e. dynamic layout, constantly changing images, etc.), or are the
files/filenames mostly static, with periodic content updates? If it's
the latter, then why download the files? I believe there are ways to
retrieve & examine just the HTTP headers of the files (to check the
content size, date/time last updated, etc.) to get an idea if the file
has been changed.
Other people are likely to have even better ideas than me...
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden