Re: Why is VS 2005 so slow?
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sat, 09 Dec 2006 17:49:37 -0500
You are confusing physical memory with virtual memory. If you have a 128K machine, you
can run a couple dozen programs, each of which takes 1GB. If you have a 4GB machine, you
can run a couple dozen programs, each of which takes 1GB. If you have a 16GB machine
(running Windows Server) you can run a couple dozen programs, each of which takes 1GB. The
difference is in the performance of the system. The performance of the 128K machine will
probably suck, because of the huge number of page faults you will have to process as each
process forces pages from some other process out so it can run, only to have the next
thread it schedules be in the process whose pages it forced out, so you'll page fault like
crazy again. It's called "page thrashing". In the 16GB machine, all the processes will
happily fit into the available RAM and there will be NO page faults (unless you use one of
those "optimizer" programs Mark Russinovich labeled "fraudware"), and you will get quite
different performance. Physical and virtual memory have no real correlation, except as
reflected by overall system performance.
Without the /3GB boot option plus /LARGEADDRESSAWARE on the executable, no executable can
see more than 2GB of virtual memory, INDEPENDENT OF THE AMOUNT OF PHYSICAL MEMORY ON YOUR
SYSTEM. If you have a server with 16GB, no process can use more than 2GB of virtual
memory (in Win32). If you have an old laptop with 128K of memory, no process can use more
than 2GB of virtual memory (in Win32). Same restriction. So I put 4GB of RAM on my
machine to improve the performance (in the article cited elsewhere in this thread, it
turns out that Windows Workstation Edition will not use more than 4GB of physical memory).
Note also that the number of apps you can run at the same time doesn't change. But the
system performance while running them (the effective performance of each individual app)
changes drastically with the amount of physical memory.
I do a lot of image editing, so I wanted lots of RAM.
Note that using the /3GB switch CAN limit the number of apps you can run, because every
app takes up a chunk of kernel space, and the kernel space has been reduced in /3GB to
1GB. So you may hit kernel resource limits. But the apps have to be fairly profligate of
kernel resources for this to be a problem.
/3GB was added so that SQL Server, IIS, and other "memory hogs" that want to do "smart
caching" of data in a domain-specific fashion could have another 1GB of RAM to use. The
serious DB people I know are moving to Win64 as fast as they can port, because they can't
tolerate tiny address spaces like 2GB or 3GB. They want as many GB of memory as they can
get, both virtual (to ease the programming issues) and physical (to improve the
performance). Right now the biggest I know of is a quad-processor 32GB Win64 box, but I
can't say who has it or what they're doing with it.
The only way you can get more than 2GB in Win32 is either to boot with /3GB or move to
Win64 (where you can get 4GB of user space for a Win32 app running under Win64). Adding
more physical memory to your machine won't change this limit.
joe
On Fri, 8 Dec 2006 13:29:04 -0800, "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Joseph M. Newcomer [MVP]
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:hehjn2dtpao3b0smtnra95bpkqqlek9qnr@xxxxxxxxxx
Any WIn32 box can be configured to boot with a 3GB user partition (add the
/3GB option to
the boot.ini file), but that cuts the kernel space down to 1GB, which can
lead to other
problems, especially for device driver writers who are too profligate of
kernel memory,
and it can also mean that certain user apps that wrote large buffers of
data may cease
working under a /3GB configuration (it relates to the ability of
GetSystemAddressForMdlSafe to map the large buffer into kernel space, but
that's a fairly
long discussion in the driver course I teach, so I'm not going to go into
it here. A
device driver writer can use MmBuildPartialMdl to work around this...).
An app can't use
more than 2GB of virtual space (even in a /3GB configuration) unless it is
linked with the
/LARGEADDRESSAWARE flag, or you run the imgcfg with the -l (that's a
lower-case L) option
on the executable image. If you are running a Win64 machine, a
/LARGEADDRESSAWARE
executable can use nearly 4GB of user virtual memory, because all the
kernel interface
DLLs live outside the 32-bit space (it's serious magic)
So now I'm confused. If I were to put 4 GB of RAM into my Dell running
WinXP Pro (32-bit), would I have 4 GB RAM to load my apps into or not? I
don't run any apps that need GB of RAM all for themselves, I just want to
run more apps at the same time. I'm just asking as a normal consumer
here... how much RAM can I buy that will work?
Thanks,
David
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: Why is VS 2005 so slow?
- From: David Ching
- Re: Why is VS 2005 so slow?
- References:
- Why is VS 2005 so slow?
- From: JD
- Re: Why is VS 2005 so slow?
- From: Doug Harrison [MVP]
- Re: Why is VS 2005 so slow?
- From: Joseph M . Newcomer
- Re: Why is VS 2005 so slow?
- From: David Ching
- Re: Why is VS 2005 so slow?
- From: Pete Delgado
- Re: Why is VS 2005 so slow?
- From: Joseph M . Newcomer
- Re: Why is VS 2005 so slow?
- From: David Ching
- Why is VS 2005 so slow?
- Prev by Date: Re: Unicode characters with VC6
- Next by Date: Re: why the window created in UI thread can't recive message?
- Previous by thread: Re: Why is VS 2005 so slow?
- Next by thread: Re: Why is VS 2005 so slow?
- Index(es):
Relevant Pages
|
Loading