Re: Monitoring swapping ...
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Jul 11, 2007, at 12:04 PM, darwin-dev-request@lists.apple.com wrote: I have an application that uses enough memory (Gigabytes) that it sometimes slows way down because of swapping. I'd like to be able to tell the user when that happens, so the user will not give up in disgust. My application is threaded, and the swapping generally takes place in one particular thread, so I could in principle have another thread monitor and report. But I am not familiar enough with low-level Unix memory-management stuff to know whether there is any way to track what is going on, or even where to start to look. Can anyone offer advice or suggestions? (The application's design pattern is model-view-controller. The model is in one thread; it is pretty much straight C++, and that's where the swapping takes place. The view and controller use another thread or two; They are pretty conventional Cocoa/Objective-C/Interface-Builder, and that's where it would be easiest to track swapping and report to the user.) = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Rather than attempting to detect one reason why your work thread would be making less forward progress, how about detecting the rate of forward progress that the thread is making? Since this is the thing that you actually care about, it makes more sense to monitor it directly rather than guess at what might be making it slow. Once you have decided what might be an acceptable rate of forward progress, you can caution the user (please, do not use a modal dialog!) that progress is slower than expected and offer suggestions as to how to determine what might be the cause (suggest you advise them on the use of Activity Monitor). This email sent to site_archiver@lists.apple.com
participants (1)
-
Michael Smith