|
|
We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512
MB of RAM.
The machine runs a name brand small business accounting package.
Every day users enter various inputs by hand and then tell the program
to post the inputs. The problem is that the posting can take up to an
hour to run. (I'm talking about the time the program runs after the
user has entered the data and told the program to post.) No other
programs have a noticeable performance problem.
I know that a half a Gig of RAM sounds skimpy for Windows XP but I
want to be sure that a lack of memory is the problem before we buy
some more memory.
Task Manager tells me that the total physical memory is 523,276 bytes
and the commit charge peak is 384,836. (I've confirmed that the last
reboot was well before the last time the accounting package was run so
this commit charge peak value includes the running of the accounting
package posting.)
I also ran a log session of the Windows Performance MMC utility for
two days. It covered two days of normal activity including the
posting. Here are the relevant counters during the time period in
which the posting was running:
(values are average, max)
Memory: Page Faults/sec = 342, 1056
Memory: Page Reads/sec = 6.5, 16.1
Logical Disk: % Disk Read time = 24.9, 117
Logical Disk: Disk Reads/sec = 6.6, 16.1
Logical Disk: Avg. Disk Read Queue Length = 0.25, 1.17
I don't know what to make of this. A half a Gig of RAM seems low for
Windows XP yet the fact that the commit charge peak is less than the
size of physical memory seems to say that the maximum of memory
demanded is less than my physical memory so RAM is not my problem.
Then the high rate of disk reads due to virtual memory (peaking at
16.1) seems to say that memory is the bottleneck.
Can someone tell me how to interpret this picture and if more memory
will speed up the accounting package posting?
Thanks.
|
|
How much memory you need is a function of how memory-intensive your
applications are. 512MB could be a perfectly reasonable amount of memory
for Windows XP plus a commercial accounting package, depending on what
else is installed. If you have any doubts, rather than tech yourself
into a lather, ask the maker of your accounting package how much RAM
they recommend.
The best reason for adding another 512MB is that, if your computer is of
reasonably recent vintage, RAM is relatively cheap now.
---
Leonard Grey
Errare humanum est
zaster39sap[ at ]yahoo.com wrote:
[Quoted Text] > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512
> MB of RAM.
>
> The machine runs a name brand small business accounting package.
> Every day users enter various inputs by hand and then tell the program
> to post the inputs. The problem is that the posting can take up to an
> hour to run. (I'm talking about the time the program runs after the
> user has entered the data and told the program to post.) No other
> programs have a noticeable performance problem.
>
> I know that a half a Gig of RAM sounds skimpy for Windows XP but I
> want to be sure that a lack of memory is the problem before we buy
> some more memory.
>
> Task Manager tells me that the total physical memory is 523,276 bytes
> and the commit charge peak is 384,836. (I've confirmed that the last
> reboot was well before the last time the accounting package was run so
> this commit charge peak value includes the running of the accounting
> package posting.)
>
> I also ran a log session of the Windows Performance MMC utility for
> two days. It covered two days of normal activity including the
> posting. Here are the relevant counters during the time period in
> which the posting was running:
>
> (values are average, max)
> Memory: Page Faults/sec = 342, 1056
> Memory: Page Reads/sec = 6.5, 16.1
> Logical Disk: % Disk Read time = 24.9, 117
> Logical Disk: Disk Reads/sec = 6.6, 16.1
> Logical Disk: Avg. Disk Read Queue Length = 0.25, 1.17
>
> I don't know what to make of this. A half a Gig of RAM seems low for
> Windows XP yet the fact that the commit charge peak is less than the
> size of physical memory seems to say that the maximum of memory
> demanded is less than my physical memory so RAM is not my problem.
> Then the high rate of disk reads due to virtual memory (peaking at
> 16.1) seems to say that memory is the bottleneck.
>
> Can someone tell me how to interpret this picture and if more memory
> will speed up the accounting package posting?
>
> Thanks.
|
|
zaster39sap[ at ]yahoo.com wrote:
[Quoted Text] > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with
> 512 MB of RAM.
>
> The machine runs a name brand small business accounting package.
> Every day users enter various inputs by hand and then tell the
> program to post the inputs. The problem is that the posting can
> take up to an hour to run. (I'm talking about the time the program
> runs after the user has entered the data and told the program to
> post.) No other programs have a noticeable performance problem.
>
> I know that a half a Gig of RAM sounds skimpy for Windows XP but I
> want to be sure that a lack of memory is the problem before we buy
> some more memory.
>
> Task Manager tells me that the total physical memory is 523,276
> bytes and the commit charge peak is 384,836. (I've confirmed that
> the last reboot was well before the last time the accounting
> package was run so this commit charge peak value includes the
> running of the accounting package posting.)
>
> I also ran a log session of the Windows Performance MMC utility for
> two days. It covered two days of normal activity including the
> posting. Here are the relevant counters during the time period in
> which the posting was running:
>
> (values are average, max)
> Memory: Page Faults/sec = 342, 1056
> Memory: Page Reads/sec = 6.5, 16.1
> Logical Disk: % Disk Read time = 24.9, 117
> Logical Disk: Disk Reads/sec = 6.6, 16.1
> Logical Disk: Avg. Disk Read Queue Length = 0.25, 1.17
>
> I don't know what to make of this. A half a Gig of RAM seems low
> for Windows XP yet the fact that the commit charge peak is less
> than the size of physical memory seems to say that the maximum of
> memory demanded is less than my physical memory so RAM is not my
> problem. Then the high rate of disk reads due to virtual memory
> (peaking at
> 16.1) seems to say that memory is the bottleneck.
>
> Can someone tell me how to interpret this picture and if more memory
> will speed up the accounting package posting?
From what you have given - I cannot say that more memory would hurt
(depending on the computer - spending the $15-$30 and 20 minutes downtime to
double+ the memory probably is not the worst choice in the world) - but it
does not seem to be the culprit.
What is 'post the inputs'? How is that done? Over a network?
Or does it do something special to said inputs - some processing?
Pentium 4 is fairly old at this point - Core2Duo, etc is more the 'standard'
now.. Or at least dual core.
BTW - you can *name* the package. This is not some sort of advertisement -
you may find someone who will read the posting with the name and go, "OH!
Yeah - had that issue - call the company and get this DLL file from them -
it will fix that!" - you never know.
Actually - have you called the software manufacturer?
--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html
|
|
What "name brand small business accounting package"?
What are the system requirements for the software?
How much history is being retained?
How many computers are sharing access?
The commit charge does not suggest RAM is the problem but how typical is
the figure?
--
Hope this helps.
Gerry
~~~~
FCA
Stourport, England
Enquire, plan and execute
~~~~~~~~~~~~~~~~~~~
zaster39sap[ at ]yahoo.com wrote:
[Quoted Text] > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512
> MB of RAM.
>
> The machine runs a name brand small business accounting package.
> Every day users enter various inputs by hand and then tell the program
> to post the inputs. The problem is that the posting can take up to an
> hour to run. (I'm talking about the time the program runs after the
> user has entered the data and told the program to post.) No other
> programs have a noticeable performance problem.
>
> I know that a half a Gig of RAM sounds skimpy for Windows XP but I
> want to be sure that a lack of memory is the problem before we buy
> some more memory.
>
> Task Manager tells me that the total physical memory is 523,276 bytes
> and the commit charge peak is 384,836. (I've confirmed that the last
> reboot was well before the last time the accounting package was run so
> this commit charge peak value includes the running of the accounting
> package posting.)
>
> I also ran a log session of the Windows Performance MMC utility for
> two days. It covered two days of normal activity including the
> posting. Here are the relevant counters during the time period in
> which the posting was running:
>
> (values are average, max)
> Memory: Page Faults/sec = 342, 1056
> Memory: Page Reads/sec = 6.5, 16.1
> Logical Disk: % Disk Read time = 24.9, 117
> Logical Disk: Disk Reads/sec = 6.6, 16.1
> Logical Disk: Avg. Disk Read Queue Length = 0.25, 1.17
>
> I don't know what to make of this. A half a Gig of RAM seems low for
> Windows XP yet the fact that the commit charge peak is less than the
> size of physical memory seems to say that the maximum of memory
> demanded is less than my physical memory so RAM is not my problem.
> Then the high rate of disk reads due to virtual memory (peaking at
> 16.1) seems to say that memory is the bottleneck.
>
> Can someone tell me how to interpret this picture and if more memory
> will speed up the accounting package posting?
>
> Thanks.
|
|
I appreciate the answers I'm getting here and I know I could slap some
more memory in but I'd like to learn how to use the Performance
utility. The problem of slow performance comes up now and then on
other machines and programs I'd like to be able to tell for sure what
the problem is.
The commit charge peak/physical memory comparison says one thing and
the memory disk read rate says another. This seems like a big
discrepancy and I'd like to understand it.
I've been studying Microsoft's tutorial on the Performance program.
Is there a better way to learn the program?
The name of the accounting package is Peachtree Complete Accounting
2004. Nothing is being done over a network. All I know about the
posting is that the user enters sales orders, payments and other
inputs, clicks a button and the program starts to "post" the inputs I
assume by updating lots of records and probably doing some
calculations.
Thanks again.
|
|
A-ha! So your /real/ question is how to use the performance measurement
utilities in Windows XP. ;-)
A newsgroup is not a good place for a tutorial (on any topic.) Your best
friend for that is Google.
Personally, what motivated me to upgrade my RAM from 512MB to 1GB was a
rebate from Crucial.
Advice for pre-2007 versions of Peachtree Complete Accounting are here
(bugger of a link):
http://kb.sagesoftwareonline.com/cgi-bin/sagesoftwareonline.cfg/php/enduser/std_adp.php?p_faqid=208&p_created=1008108680&p_sid=Id94y5mj&p_accessibility=0&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MyZwX3Byb2RzPTEzJnBfY2F0cz0mcF9wdj0xLjEzJnBfY3Y9JnBfc2VhcmNoX3R5cGU9YW5zd2Vycy5zZWFyY2hfbmwmcF9wYWdlPTEmcF9zZWFyY2hfdGV4dD1SQU0*&site_ID=&p_li=&p_topview=1
If the link is too long, you can find the information the Peachtree
Knowledgebase for pre-2007 versions of the product. In short, they
recommend 128MB or more, so I think you're fine with 512MB.
---
Leonard Grey
Errare humanum est
zaster39sap[ at ]yahoo.com wrote:
[Quoted Text] > I appreciate the answers I'm getting here and I know I could slap some
> more memory in but I'd like to learn how to use the Performance
> utility. The problem of slow performance comes up now and then on
> other machines and programs I'd like to be able to tell for sure what
> the problem is.
>
> The commit charge peak/physical memory comparison says one thing and
> the memory disk read rate says another. This seems like a big
> discrepancy and I'd like to understand it.
>
> I've been studying Microsoft's tutorial on the Performance program.
> Is there a better way to learn the program?
>
> The name of the accounting package is Peachtree Complete Accounting
> 2004. Nothing is being done over a network. All I know about the
> posting is that the user enters sales orders, payments and other
> inputs, clicks a button and the program starts to "post" the inputs I
> assume by updating lots of records and probably doing some
> calculations.
>
> Thanks again.
>
|
|
<zaster39sap[ at ]yahoo.com> wrote in message
news:80a0a7d4-87d1-4b0b-8e05-640baf5c02b6[ at ]s24g2000vbp.googlegroups.com...
[Quoted Text] > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512
> MB of RAM.
>
> The machine runs a name brand small business accounting package.
> Every day users enter various inputs by hand and then tell the program
> to post the inputs. The problem is that the posting can take up to an
> hour to run. (I'm talking about the time the program runs after the
> user has entered the data and told the program to post.) No other
> programs have a noticeable performance problem.
>
> I know that a half a Gig of RAM sounds skimpy for Windows XP but I
> want to be sure that a lack of memory is the problem before we buy
> some more memory.
>
> Task Manager tells me that the total physical memory is 523,276 bytes
> and the commit charge peak is 384,836. (I've confirmed that the last
> reboot was well before the last time the accounting package was run so
> this commit charge peak value includes the running of the accounting
> package posting.)
>
> I also ran a log session of the Windows Performance MMC utility for
> two days. It covered two days of normal activity including the
> posting. Here are the relevant counters during the time period in
> which the posting was running:
>
> (values are average, max)
> Memory: Page Faults/sec = 342, 1056
> Memory: Page Reads/sec = 6.5, 16.1
> Logical Disk: % Disk Read time = 24.9, 117
> Logical Disk: Disk Reads/sec = 6.6, 16.1
> Logical Disk: Avg. Disk Read Queue Length = 0.25, 1.17
>
> I don't know what to make of this. A half a Gig of RAM seems low for
> Windows XP yet the fact that the commit charge peak is less than the
> size of physical memory seems to say that the maximum of memory
> demanded is less than my physical memory so RAM is not my problem.
> Then the high rate of disk reads due to virtual memory (peaking at
> 16.1) seems to say that memory is the bottleneck.
>
> Can someone tell me how to interpret this picture and if more memory
> will speed up the accounting package posting?
>
> Thanks.
The page fault rate seems a little high to me. More memory would help.
Jim
|
|
Peachtree Complete Accounting 2004 is entry level software. The Company
is now owned by Sage. I use a more sophisticated Sage package in the UK.
The Peachtree software does not have testing system requirements.
http://www.geminicomputersinc.com/pecoacfurebo.html
This suggests to me it is the way the software is being used that is
creating the problem. As I said earlier how much history is being
carried? How many open transactions are in the audit trail?
More information on what you mean by this would be helpful "Every day
users enter various inputs by hand and then tell the program to post the
inputs. The problem is that the posting can take up to an hour to run.
(I'm talking about the time the program runs after the user has entered
the data and told the program to post.)". Are you importing data? If yes
in what form?
As this is entry level software the problem could be the number of
transactions to be processed is more than the system was designed to
handle?
http://snipurl.com/91jh8 [kb_sagesoftwareonline_com]
This might be more helpful
http://snipurl.com/91jk9 [kb_sagesoftwareonline_com]
--
Hope this helps.
Gerry
~~~~
FCA
Stourport, England
Enquire, plan and execute
~~~~~~~~~~~~~~~~~~~
zaster39sap[ at ]yahoo.com wrote:
[Quoted Text] > I appreciate the answers I'm getting here and I know I could slap some
> more memory in but I'd like to learn how to use the Performance
> utility. The problem of slow performance comes up now and then on
> other machines and programs I'd like to be able to tell for sure what
> the problem is.
>
> The commit charge peak/physical memory comparison says one thing and
> the memory disk read rate says another. This seems like a big
> discrepancy and I'd like to understand it.
>
> I've been studying Microsoft's tutorial on the Performance program.
> Is there a better way to learn the program?
>
> The name of the accounting package is Peachtree Complete Accounting
> 2004. Nothing is being done over a network. All I know about the
> posting is that the user enters sales orders, payments and other
> inputs, clicks a button and the program starts to "post" the inputs I
> assume by updating lots of records and probably doing some
> calculations.
>
> Thanks again.
|
|
On Tue, 23 Dec 2008 07:39:15 -0800 (PST), zaster39sap[ at ]yahoo.com wrote:
[Quoted Text] > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512
> MB of RAM.
>
> The machine runs a name brand small business accounting package.
> Every day users enter various inputs by hand and then tell the program
> to post the inputs. The problem is that the posting can take up to an
> hour to run. (I'm talking about the time the program runs after the
> user has entered the data and told the program to post.) No other
> programs have a noticeable performance problem.
>
> I know that a half a Gig of RAM sounds skimpy for Windows XP but I
> want to be sure that a lack of memory is the problem before we buy
> some more memory.
No, 512MB is not necessarily skimpy at all, and it's fine for many
people. How much RAM you need for good performance is *not* a
one-size-fits-all situation. You get good performance if the amount of
RAM you have keeps you from using the page file, and that depends on
what apps you run. Most people running a typical range of business
applications find that somewhere around 512MB (or even a little less)
works well, others need more. Almost anyone will see poor performance
with less than 256MB. Some people, particularly those doing things
like editing large photographic images, can see a performance boost by
adding even more than 512MB--sometimes much more.
If you are currently using the page file significantly, more memory
will decrease or eliminate that usage, and improve your performance.
If you are not using the page file significantly, more memory will do
nothing for you. Go to
http://billsway.com/notes%5Fpublic/winxp%5Ftweaks/ and download
WinXP-2K_Pagefile.zip and monitor your pagefile usage. That should
give you a good idea of whether more memory can help, and if so, how
much more.
When you say "The problem is that the posting can take up to an hour
to run. (I'm talking about the time the program runs after the user
has entered the data and told the program to post.) No other programs
have a noticeable performance problem" it may be that that program
needs more RAM than the others you run, or it may be that something is
wrong with that program. It's very difficult to guess what the problem
might be without even knowing the name of the program.
--
Ken Blake, Microsoft MVP - Windows Desktop Experience
Please Reply to the Newsgroup
|
|
On Dec 23, 1:27 pm, "Ken Blake, MVP"
<kbl...[ at ]this.is.an.invalid.domain> wrote:
[Quoted Text] > On Tue, 23 Dec 2008 07:39:15 -0800 (PST), zaster39...[ at ]yahoo.com wrote: > > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512 > > MB of RAM. > > > The machine runs a name brand small business accounting package. > > Every day users enter various inputs by hand and then tell the program > > to post the inputs. The problem is that the posting can take up to an > > hour to run. (I'm talking about the time the program runs after the > > user has entered the data and told the program to post.) No other > > programs have a noticeable performance problem. > > > I know that a half a Gig of RAM sounds skimpy for Windows XP but I > > want to be sure that a lack of memory is the problem before we buy > > some more memory. > > No, 512MB is not necessarily skimpy at all, and it's fine for many > people. How much RAM you need for good performance is *not* a > one-size-fits-all situation. You get good performance if the amount of > RAM you have keeps you from using the page file, and that depends on > what apps you run. Most people running a typical range of business > applications find that somewhere around 512MB (or even a little less) > works well, others need more. Almost anyone will see poor performance > with less than 256MB. Some people, particularly those doing things > like editing large photographic images, can see a performance boost by > adding even more than 512MB--sometimes much more. > > If you are currently using the page file significantly, more memory > will decrease or eliminate that usage, and improve your performance. > If you are not using the page file significantly, more memory will do > nothing for you. Go to http://billsway.com/notes%5Fpublic/winxp%5Ftweaks/and download > WinXP-2K_Pagefile.zip and monitor your pagefile usage. That should > give you a good idea of whether more memory can help, and if so, how > much more. > > When you say "The problem is that the posting can take up to an hour > to run. (I'm talking about the time the program runs after the user > has entered the data and told the program to post.) No other programs > have a noticeable performance problem" it may be that that program > needs more RAM than the others you run, or it may be that something is > wrong with that program. It's very difficult to guess what the problem > might be without even knowing the name of the program. > > -- > Ken Blake, Microsoft MVP - Windows Desktop Experience > Please Reply to the Newsgroup
Ken,
Thanks for your reply. I give the name of the program and a little
more info about the problem in a reply post above.
Isn't the Performance program the gold standard for answering
questions about program performance? I thought that it allowed you to
not rely on rules of thumb, guesses or software manufacturers' claims
and actually see where the bottleneck is.
How is the pagefile usage utility you recommend better than trying to
check memory shortage via the Performance program?
Is this the right forum for questions about the Performance program?
|
|
On Dec 23, 1:27 pm, "Ken Blake, MVP"
<kbl...[ at ]this.is.an.invalid.domain> wrote:
[Quoted Text] > On Tue, 23 Dec 2008 07:39:15 -0800 (PST), zaster39...[ at ]yahoo.com wrote: > > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512 > > MB of RAM. > > > The machine runs a name brand small business accounting package. > > Every day users enter various inputs by hand and then tell the program > > to post the inputs. The problem is that the posting can take up to an > > hour to run. (I'm talking about the time the program runs after the > > user has entered the data and told the program to post.) No other > > programs have a noticeable performance problem. > > > I know that a half a Gig of RAM sounds skimpy for Windows XP but I > > want to be sure that a lack of memory is the problem before we buy > > some more memory. > > No, 512MB is not necessarily skimpy at all, and it's fine for many > people. How much RAM you need for good performance is *not* a > one-size-fits-all situation. You get good performance if the amount of > RAM you have keeps you from using the page file, and that depends on > what apps you run. Most people running a typical range of business > applications find that somewhere around 512MB (or even a little less) > works well, others need more. Almost anyone will see poor performance > with less than 256MB. Some people, particularly those doing things > like editing large photographic images, can see a performance boost by > adding even more than 512MB--sometimes much more. > > If you are currently using the page file significantly, more memory > will decrease or eliminate that usage, and improve your performance. > If you are not using the page file significantly, more memory will do > nothing for you. Go to http://billsway.com/notes%5Fpublic/winxp%5Ftweaks/and download > WinXP-2K_Pagefile.zip and monitor your pagefile usage. That should > give you a good idea of whether more memory can help, and if so, how > much more. > > When you say "The problem is that the posting can take up to an hour > to run. (I'm talking about the time the program runs after the user > has entered the data and told the program to post.) No other programs > have a noticeable performance problem" it may be that that program > needs more RAM than the others you run, or it may be that something is > wrong with that program. It's very difficult to guess what the problem > might be without even knowing the name of the program. > > -- > Ken Blake, Microsoft MVP - Windows Desktop Experience > Please Reply to the Newsgroup
Ken,
Thanks for your reply. I give the name of the program and a little
more info about the problem in a reply post above.
Isn't the Performance program the gold standard for answering
questions about program performance? I thought that it allowed you to
not rely on rules of thumb, guesses or software manufacturers' claims
and actually see where the bottleneck is.
How is the pagefile usage utility you recommend better than trying to
check memory shortage via the Performance program?
Is this the right forum for questions about the Performance program?
|
|
On Dec 23, 1:27 pm, "Ken Blake, MVP"
<kbl...[ at ]this.is.an.invalid.domain> wrote:
[Quoted Text] > On Tue, 23 Dec 2008 07:39:15 -0800 (PST), zaster39...[ at ]yahoo.com wrote: > > We have a PC with a 2.0 GHz Pentium 4 running Windows XP Pro with 512 > > MB of RAM. > > > The machine runs a name brand small business accounting package. > > Every day users enter various inputs by hand and then tell the program > > to post the inputs. The problem is that the posting can take up to an > > hour to run. (I'm talking about the time the program runs after the > > user has entered the data and told the program to post.) No other > > programs have a noticeable performance problem. > > > I know that a half a Gig of RAM sounds skimpy for Windows XP but I > > want to be sure that a lack of memory is the problem before we buy > > some more memory. > > No, 512MB is not necessarily skimpy at all, and it's fine for many > people. How much RAM you need for good performance is *not* a > one-size-fits-all situation. You get good performance if the amount of > RAM you have keeps you from using the page file, and that depends on > what apps you run. Most people running a typical range of business > applications find that somewhere around 512MB (or even a little less) > works well, others need more. Almost anyone will see poor performance > with less than 256MB. Some people, particularly those doing things > like editing large photographic images, can see a performance boost by > adding even more than 512MB--sometimes much more. > > If you are currently using the page file significantly, more memory > will decrease or eliminate that usage, and improve your performance. > If you are not using the page file significantly, more memory will do > nothing for you. Go to http://billsway.com/notes%5Fpublic/winxp%5Ftweaks/and download > WinXP-2K_Pagefile.zip and monitor your pagefile usage. That should > give you a good idea of whether more memory can help, and if so, how > much more. > > When you say "The problem is that the posting can take up to an hour > to run. (I'm talking about the time the program runs after the user > has entered the data and told the program to post.) No other programs > have a noticeable performance problem" it may be that that program > needs more RAM than the others you run, or it may be that something is > wrong with that program. It's very difficult to guess what the problem > might be without even knowing the name of the program. > > -- > Ken Blake, Microsoft MVP - Windows Desktop Experience > Please Reply to the Newsgroup
Ken,
Thanks for your reply. I give the name of the program and a little
more info about the problem in a reply post above.
Isn't the Performance program the gold standard for answering
questions about program performance? I thought that it allowed you to
not rely on rules of thumb, guesses or software manufacturers' claims
and actually see where the bottleneck is.
How is the pagefile usage utility you recommend better than trying to
check memory shortage via the Performance program?
Is this the right forum for questions about the Performance program?
|
|
|