Installing XP

On Mon, 31 Dec 2007 10:53:59 -0800, "Sam Hobbs"
wrote:

"Ken Blake, MVP" wrote in message
...

2. How long it takes XP to start is inconsequential for most people.

In this context, I consider startup time to be an indication of XP's
performance using the configuration it is in. Yes, it does depend on
whatever else is starting so bad performance at startup might be misleading


Although I don't disagree, in my view that "might" should be changed
to "is usually," or at least "is often."


but if that is acknowledged as an influence then poor performance by the
startup is a possible indication of overall poor performance.


Possible, yes. But often not. If overall performance *is* poor, then
it should be addressed, and what you have starting automatically
should certainly be looked at as a possible cause of poor performance.
But it's wrong to assume that slow startup automatically means poor
general performance.

I think many people mistakenly assume that a slow startup slows down
everything else, but that's not always (maybe not even usually) the
case.

That's why my standard newsgroup post on slow startup includes the
sentence "Assuming that the computer's speed is otherwise
satisfactory, it may not be worth worrying about."

My own system is a very good case in point. It starts extremely
slowly, because I automatically start a number of applications (not
just background ones) that I use and always keep open all day. These
include Outlook, Forte Agent, Excel, IE7 with Maxthon running on top
of it, and Quicken. If I didn't start them automatically, I would
start them manually just after startup, and it's easier to do it
automatically.

Starting all those programs automatically makes a very slow startup,
but after startup, my performance is just fine.


Definitely if the poor performance only occurs during startup then most
people could live with that.


Yes, that is exactly the point I was making.

--
Ken Blake, Microsoft MVP Windows - Shell/User
Please Reply to the Newsgroup

"Daave" wrote in message
...

256 MB is ample and Commit Charge figures verify this.

I don't understand how Commit Charge figures are relevant. See the following
article; it's description of the Commit Charge figures does not indicate a
relevance.

The Memory Shell Game
http://blogs.msdn.com/ntdebugging/ar...hell-game.aspx

"Ken Blake, MVP" wrote in message
...

I think many people mistakenly assume that a slow startup slows down
everything else

I don't. If anything I said indicates otherwise then I was not clear.

My own system is a very good case in point. It starts extremely
slowly, because I automatically start a number of applications (not
just background ones) that I use and always keep open all day. These
include Outlook, Forte Agent, Excel, IE7 with Maxthon running on top
of it, and Quicken. If I didn't start them automatically, I would
start them manually just after startup, and it's easier to do it
automatically.

That's great if the system can do all that without the multiple processes
causing paging that would not occur when there is less for the system to do.
If there is a lot of paging (thrashing) caused by Windows trying to do so
much that it is forced to do a lot of physical paging (hard faults) that it
would not need to do with a lighter workload then it would be reasonable to
reduce the workload during startup.

Caffeine does not alleviate slow startups. Slow startup are annoying no
matter how much caffeine is ingested.
"Bill Sharpe" wrote in message
...
Unknown wrote:
That of course is YOU personally. I power up my computer AFTER coffee and
a long
bootup time is annoying.

Geez, have a second cup of coffee and relax...

Bill

Sam Hobbs wrote:
"Daave" wrote in message
...

256 MB is ample and Commit Charge figures verify this.

I don't understand how Commit Charge figures are relevant. See the
following article; it's description of the Commit Charge figures does
not indicate a relevance.

The Memory Shell Game

http://blogs.msdn.com/ntdebugging/ar...hell-game.aspx

This is my understanding:

If the peak level is less than the amount of RAM, the PC doesn't need to
use the pagefile (therefore, performance is at optimal level). I believe
that article was addressing whenever the commit charge is *higher* than
the amount of RAM, the amount of thrashing may not be as high as one
might expect, depending on whether or not I/O is kept to a minimum.

On Mon, 31 Dec 2007 13:39:55 -0800, "Sam Hobbs"
wrote:

"Ken Blake, MVP" wrote in message
...

I think many people mistakenly assume that a slow startup slows down
everything else

I don't. If anything I said indicates otherwise then I was not clear.


Sorry--no, I didn't think you did. I was pointing that others do, and
that's why I so often stress that a slow startup, in and of itself, is
not necessarily a problem, and for many people often isn't.


My own system is a very good case in point. It starts extremely
slowly, because I automatically start a number of applications (not
just background ones) that I use and always keep open all day. These
include Outlook, Forte Agent, Excel, IE7 with Maxthon running on top
of it, and Quicken. If I didn't start them automatically, I would
start them manually just after startup, and it's easier to do it
automatically.

That's great if the system can do all that without the multiple processes
causing paging that would not occur when there is less for the system to do.
If there is a lot of paging (thrashing) caused by Windows trying to do so
much that it is forced to do a lot of physical paging (hard faults) that it
would not need to do with a lighter workload then it would be reasonable to
reduce the workload during startup.



Again, the thrashing would occur if several of the programs are in
simultaneous use. Since I keep all these loaded because I use one or
the other frequently throughout the day, but hardly ever use multiples
at the same time, they don't compete with each other for RAM, and
thrashing is not an issue. Performance is fine.


--
Ken Blake, Microsoft MVP Windows - Shell/User
Please Reply to the Newsgroup

"Daave" wrote in message
...
Sam Hobbs wrote:
"Daave" wrote in message
...

256 MB is ample and Commit Charge figures verify this.

I don't understand how Commit Charge figures are relevant. See the
following article; it's description of the Commit Charge figures does
not indicate a relevance.

The Memory Shell Game

http://blogs.msdn.com/ntdebugging/ar...hell-game.aspx

This is my understanding:

If the peak level is less than the amount of RAM, the PC doesn't need to
use the pagefile (therefore, performance is at optimal level). I believe
that article was addressing whenever the commit charge is *higher* than
the amount of RAM, the amount of thrashing may not be as high as one
might expect, depending on whether or not I/O is kept to a minimum.


Probably you are correct that if physical memory is adequate enough to
provide all the memory for all the applications executing then the pagefile
is not needed. The assumption is that physical memory is often not adequate,
however processes usually have some memory that is used so rarely that it is
efficient to page out the memory that is rarely used. If however there is
enough physical memory then it still is not necessary to page anything out.
If that is the case then there is no need to discuss anything here; anyone
with sufficient main memory can ignore this. The problem is when there is
such an inadequate supply of main memory that there are performance problems
due to that problem.

Yes, it is true that "whenever the commit charge is *higher* than the amount
of RAM, the amount of thrashing may not be as high as one might expect" but
it is also true that the amount of thrashing might be higher than one might
expect; both situations are possible and the commit charge does not indicate
which is true.

"Ken Blake, MVP" wrote in message
...

Again, the thrashing would occur if several of the programs are in
simultaneous use. Since I keep all these loaded because I use one or
the other frequently throughout the day, but hardly ever use multiples
at the same time, they don't compete with each other for RAM, and
thrashing is not an issue. Performance is fine.

I was referring to loading startup with many things to do during startup.
During startup, the programs will likely execute simultaneously with other
programs. This automatic execution of multiple processes could choke main
memory more than at any other time and therefore a limited amount of main
memory could force use of virtual storage. If multiple processes compete for
main memory during the unusual startup environment that occurs during
startup then they might require more time than if they executed at a less
resource-intensive time.

I am speaking theoretically; I assume it does not apply to your system.

Sam Hobbs wrote:
"Daave" wrote in message
...
Sam Hobbs wrote:
"Daave" wrote in message
...

256 MB is ample and Commit Charge figures verify this.

I don't understand how Commit Charge figures are relevant. See the
following article; it's description of the Commit Charge figures
does
not indicate a relevance.

The Memory Shell Game


http://blogs.msdn.com/ntdebugging/ar...hell-game.aspx

This is my understanding:

If the peak level is less than the amount of RAM, the PC doesn't
need to
use the pagefile (therefore, performance is at optimal level). I
believe
that article was addressing whenever the commit charge is *higher*
than
the amount of RAM, the amount of thrashing may not be as high as one
might expect, depending on whether or not I/O is kept to a minimum.


Probably you are correct that if physical memory is adequate enough to
provide all the memory for all the applications executing then the
pagefile
is not needed. The assumption is that physical memory is often not
adequate, however processes usually have some memory that is used so
rarely that it is efficient to page out the memory that is rarely
used. If however there is
enough physical memory then it still is not necessary to page
anything out.
If that is the case then there is no need to discuss anything here;
anyone
with sufficient main memory can ignore this.

That is the case. :-)

On Mon, 31 Dec 2007 18:59:19 -0800, "Sam Hobbs"
wrote:

Probably you are correct that if physical memory is adequate enough to
provide all the memory for all the applications executing then the pagefile
is not needed.


Nope, that isn't true. Applications often pre-allocate memory for
*potential* use, and in many cases, that potential use never becomes
actual use. Those allocations normally get paged out very quickly
because they are not in use, but if there is no page file they have to
stay in real memory. The result is that without a page file, you
effectively get locked out of some of your real memory, and you can't
actually use all of it.

Add to that that there is *no* advantage to not having a page file
(except for saving a tiny amount of disk space) and it's clear that it
should never to turned off.

For more information, read "Virtual Memory in Windows XP" by the late
MVP Alex Nichol at http://aumha.org/win5/a/xpvm.htm

--
Ken Blake, Microsoft MVP Windows - Shell/User
Please Reply to the Newsgroup

On Mon, 31 Dec 2007 19:08:38 -0800, "Sam Hobbs"
wrote:

"Ken Blake, MVP" wrote in message
...

Again, the thrashing would occur if several of the programs are in
simultaneous use. Since I keep all these loaded because I use one or
the other frequently throughout the day, but hardly ever use multiples
at the same time, they don't compete with each other for RAM, and
thrashing is not an issue. Performance is fine.

I was referring to loading startup with many things to do during startup.
During startup, the programs will likely execute simultaneously with other
programs. This automatic execution of multiple processes could choke main
memory more than at any other time and therefore a limited amount of main
memory could force use of virtual storage. If multiple processes compete for
main memory during the unusual startup environment that occurs during
startup then they might require more time than if they executed at a less
resource-intensive time.

I am speaking theoretically; I assume it does not apply to your system.


Well, I'm not absolutely sure I completely understand you, but if you
are saying that competition for real memory, and consequent thrashing,
occurs while the programs are being loaded at startup, yes that's
true, and I agree. I'm sure it does apply to my system, and that's
part of the reason that my startup is slow. But as I said, I start up
very seldom, and I don't mind its being slow, since performance is
otherwise fine.


--
Ken Blake, Microsoft MVP Windows - Shell/User
Please Reply to the Newsgroup

"Ken Blake, MVP" wrote in message
...
On Mon, 31 Dec 2007 18:59:19 -0800, "Sam Hobbs"
wrote:

Probably you are correct that if physical memory is adequate enough to
provide all the memory for all the applications executing then the
pagefile
is not needed.


Nope, that isn't true. Applications often pre-allocate memory for
*potential* use, and in many cases, that potential use never becomes
actual use. Those allocations normally get paged out very quickly
because they are not in use, but if there is no page file they have to
stay in real memory. The result is that without a page file, you
effectively get locked out of some of your real memory, and you can't
actually use all of it.

Add to that that there is *no* advantage to not having a page file
(except for saving a tiny amount of disk space) and it's clear that it
should never to turned off.

For more information, read "Virtual Memory in Windows XP" by the late
MVP Alex Nichol at http://aumha.org/win5/a/xpvm.htm

--
Ken Blake, Microsoft MVP Windows - Shell/User
Please Reply to the Newsgroup


What in particular in that article do you think it says that the "result is
that without a page file, you effectively get locked out of some of your
real memory, and you can't actually use all of it"?

As for "they have to stay in real memory", staying in real memory is ideal.
It is foolish to force Windows to swap anything to the pagefile if there is
enough real memory to satisfy all memory requirements for all processes
executing in a system.

The article says "the optimisation implied by this has been found not to
justify the overhead, and normally there is only a single page file in the
first instance". The author does not understand the value of using multiple
physical drives for pagefiles.

On Wed, 2 Jan 2008 00:14:00 -0800, "Sam Hobbs"
wrote:


"Ken Blake, MVP" wrote in message
...
On Mon, 31 Dec 2007 18:59:19 -0800, "Sam Hobbs"
wrote:

Probably you are correct that if physical memory is adequate enough to
provide all the memory for all the applications executing then the
pagefile
is not needed.


Nope, that isn't true. Applications often pre-allocate memory for
*potential* use, and in many cases, that potential use never becomes
actual use. Those allocations normally get paged out very quickly
because they are not in use, but if there is no page file they have to
stay in real memory. The result is that without a page file, you
effectively get locked out of some of your real memory, and you can't
actually use all of it.

Add to that that there is *no* advantage to not having a page file
(except for saving a tiny amount of disk space) and it's clear that it
should never to turned off.

For more information, read "Virtual Memory in Windows XP" by the late
MVP Alex Nichol at http://aumha.org/win5/a/xpvm.htm

--
Ken Blake, Microsoft MVP Windows - Shell/User
Please Reply to the Newsgroup


What in particular in that article do you think it says that the "result is
that without a page file, you effectively get locked out of some of your
real memory, and you can't actually use all of it"?


"Doing this would waste a lot of the RAM. The reason is that when
programs ask for an allocation of Virtual memory space, they may ask
for a great deal more than they ever actually bring into use — the
total may easily run to hundreds of megabytes. These addresses have to
be assigned to somewhere by the system. If there is a page file
available, the system can assign them to it"



As for "they have to stay in real memory", staying in real memory is ideal.
It is foolish to force Windows to swap anything to the pagefile if there is
enough real memory to satisfy all memory requirements for all processes
executing in a system.


No. We are talking here about allocations that will probably never be
used. What you say is true only for what is used.


--
Ken Blake, Microsoft MVP Windows - Shell/User
Please Reply to the Newsgroup

"Ken Blake, MVP" wrote in message
...
On Wed, 2 Jan 2008 00:14:00 -0800, "Sam Hobbs"
wrote:

What in particular in that article do you think it says that the "result
is
that without a page file, you effectively get locked out of some of your
real memory, and you can't actually use all of it"?


"Doing this would waste a lot of the RAM. The reason is that when
programs ask for an allocation of Virtual memory space, they may ask
for a great deal more than they ever actually bring into use - the
total may easily run to hundreds of megabytes. These addresses have to
be assigned to somewhere by the system. If there is a page file
available, the system can assign them to it"

That is too vague for me to be sure and I don't trust the accuracy. Let's
leave this to be judged by each person. You can help everyone by finding
something more reliable; maybe I will.

Sam Hobbs wrote:
"Ken Blake, MVP" wrote in message
...
On Wed, 2 Jan 2008 00:14:00 -0800, "Sam Hobbs"
wrote:

What in particular in that article do you think it says that the "result
is
that without a page file, you effectively get locked out of some of your
real memory, and you can't actually use all of it"?

"Doing this would waste a lot of the RAM. The reason is that when
programs ask for an allocation of Virtual memory space, they may ask
for a great deal more than they ever actually bring into use - the
total may easily run to hundreds of megabytes. These addresses have to
be assigned to somewhere by the system. If there is a page file
available, the system can assign them to it"

That is too vague for me to be sure and I don't trust the accuracy. Let's
leave this to be judged by each person. You can help everyone by finding
something more reliable; maybe I will.





Accidently launch an extra copy of a drawing program and POOF! you are
out of memory.

There is NEVER "enough" RAM to run 1 each of all your programs.