🚀 go-pugleaf

Paging in and out is a queue. When Corel#1 needs some ram, the request is 
either satisfied right away, if available, or queued. When the required ram is 
fully used, then Corel#1 waits unitl something can be freed (paged out). 
Corel#2 needs some ram and it is also queued. Then comes your process and 
wants its share of ram and it is queued. The Corels tend to page lots of pages 
at a time. Plus, Drawing programs do clean up of their memory from time to 
time. For it to free some ram, All of the pages of buffer get paged in to free 
it. This is because, running programs have no knowledge of paging - and paging 
has no idea that all the program is going to do is release it. So all these 
things on the queue in front of you will slow you down. Add to this, any other 
disk activity on the same disk as your swap file. That can cause serious 
thrashing. 

The only real answer is to add more ram or reduce the demands on the available 
ram.

I wasn't necessarily suggesting your program was the offender. Corel's low 
memory handling could be the culprit. I never used Corel, but Photoshop 
implements its own paging-temp file to be used when it runs low on memory. 
That tends to complicate the paging issue. If Corel does this, make sure it is 
on a different disk than Windows swap file. 

Bill


In article <4021eaf6@newsgroups.borland.com>, dm1@fromru.com says...
>
>Thanks for the reply. Actually I meant "physical RAM", not all virtual
>memory. Maybe I expressed the situation not exactly - my program doesn't
>have any reported by CG memory leaks or "poor handling of limit conditions"
>and runs perfectly being not minimized to taskbar irrespectively of current
>system load.
>When I also tested how it works being minimized and launched a lot of "heavy
>artillery" - say, several instances of Corel Photo Paint each tuned to
>reserve around 300 Mbytes of memory (overall RAM amount on the testing
>machine is 512 MBytes) , then after some time I couldn't awaken my program
>by clicking on it's icon in windows taskbar - simply no reaction.
>The only thing I've noticed was the amount of memory reserved by my program
>as it is shown in task manager dropped from 15 megabytes to mere 600
>kilobytes as it possibly should be when "swapping it out". I have no idea
>why my program can not be "swapped in" and thus restored...
>
>Dmitry.
>
>"BillT" <billtouch_no_spam@att.net> wrote:
>news:4021a2c0@newsgroups.borland.com...
>> It sounds like a memory leak or poor handling of limit conditions. It
>> sounds unsual for a process to eat all of system memory.
>>
>> Paging (Swapping) shouldn't be an issue beause the kernel gets the real
>memory
>> it needs from a pool of less used pages. Other pages get swapped out and
>the
>> soon to be executed pages get swapped in.
>>
>>
>> In article <40042458@newsgroups.borland.com>, dm1@fromru.com says...
>> >
>> >I ran into strange problem - when I leave my application running in
>> >backgound (most of the time it is doing nothing in this case, just
>polling
>> >email every 15 minutes) and switch to other application(s) which utilize
>all
>> >the system memory, then after some time usually I can not restore my
>> >application anymore by clicking at it's icon on windows taskbar.
>> >Usually it consumes approx. 15 MB of RAM (exe itself is 5 megabytes), but
>> >when I look at task manager I see that only 600 kbytes are kept in RAM.
>> >What can prevent an application from awakening when it is partially moved
>to
>> >swap file?
>> >
>> >Dmitry
>> >
>> >
>>
>
>