PCBUILD Archives

Personal Computer Hardware discussion List

PCBUILD@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
PCBUILD - Personal Computer Hardware discussion List <[log in to unmask]>
Date:
Fri, 16 Oct 1998 11:32:02 -0800
Reply-To:
PCBUILD - Personal Computer Hardware discussion List <[log in to unmask]>
Content-type:
text/plain; charset=US-ASCII
Subject:
From:
David Gillett <[log in to unmask]>
Content-transfer-encoding:
7BIT
In-Reply-To:
Organization:
General Magic
MIME-Version:
1.0
Parts/Attachments:
text/plain (36 lines)
On 16 Oct 98 at 10:43, John Chin wrote:

> The best solution is:  Bring your RAM up to at least 64MB and let
> Windows 98 handle your Swap File. This amount of RAM will
> substantially reduce the Windows need for virtual memory and avoid
> the attendant, time wasting Swap File management.

  I beg to respectfully disagree.  While installing more RAM will
reduce Windows' USE of the swap file, it won't affect Windows'
MANAGEMENT of the swap file at all.  [Many people still imagine the
swap file working the way it did in Windows 3.x, and that's not how
it's done in any Win32 version.]

  Specifically, swap file space is allocated because a program uses
RAM, not because there's not enough real RAM for it.  Adding RAM will
reduce the number of reads and writes of the swap file, but it won't
affect its growth and shrinkage.  A swap file managed by Windows WILL
become fragmented, if there is any other activity on that volume.

> Anyway, you are better off having a swap file using LARGE CLUSTERS,
> because they will read and write faster than many smaller clusters
> and reduce the extent of fragmentation.

  Since Win32 swapping is done in PAGES which are fixed at 4K in
size, clusters larger than this cannot really help swap file
performance.  [Actually, cluster size affects how space is allocated
to files, rather than how it is read and written.  Larger cluster
sizes will tend to soften the effects of fragmentation, but avoiding
it altogether is really a better option.]

David G

                                  -----
                PCBUILD mailing list -  http://nospin.com
         Bob Wright:[log in to unmask] - Drew Dunn:[log in to unmask]

ATOM RSS1 RSS2