[pmmail-list] Beta progress
Steve Barber
pmmail-list@blueprintsoftwareworks.com
Fri, 16 Aug 2002 23:47:12 -0400
On Fri, 16 Aug 2002 19:52:38 -0600, Martin Moran wrote:
>A question of curiosity here - I'm running what is now a low-horsepower
>machine with *gasp* only 64MB of RAM. I've noticed that after
>considerable uptime - 1 to 3 hours or so - that the machine starts to
>spiral down in speed when switching windows and doing tasks, leading me
>to believe it's a memory issue. (And yes, I get 1 to 3 hours of uptime
>with Win98, which also amazes me.)
>
>Is PMMail the culprit here? Have I missed a thread about this
>somewhere along the line?
You may be able to test this yourself ... just run a memory monitor
tool ( you don't need a fancy expensive one ... a free one like
sysmon.exe can do the job). Set it up to monitor allocated memory
1/sec or so ... if the allocated memory simply creeps up over time
while pmmail is active but doesn't when pmmail isn't active ... then
you can suspect pmmail.
You might also try watching it while PMMAIL does various things known
to be memory intensive ... I'm not sure what those might be, but I'd
watch while moving lots of emails from one folder to another ... or
while emptying a large folder ... or repeatedly sorting a folder full
of stuff ... or doing expensive searches ... or while big files are
being sent or received. Any such things could cause a slow creep
from even a small leak. The trick is to find the function that's at
the root of it and do so much of it that the slow creep becomes
noticeable without having to wait for 1 - 3 hours.
Anyone with WinNT/2000 or XP can do the same using the more detailed
performance tools there.
If you can pin down some particular activity that triggers a gradual
and steady increase in allocated memory, then it's much more likely
that they can fix it.
But, even if you are not running anything but PMMail, there are a lot
of other suspects (in Win98) that may be the culprit. If you're
running lots of other programs, then they are just as likely suspects
as PMMail.
Getting rid of big leaks is usually easy ... finding all the little
ones that only hurt after hours of trickling and are dependent on
some particular resource demand is nearly impossible.
SteveB
Steve Barber
104 Sylvan Grove
Cary, NC 27511
919-851-4244
jsbarbe@attglobal.net
- pmmail-list - The PMMail Discussion List ---------------------------
To POST to the list, send your message to:
pmmail-list@blueprintsoftwareworks.com
To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com
with the first line of the message body being...
UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com
---------------------------------------------------------------------