Hi Al,

>
>As for RAM, take a look in Task Manager at RAM usage (Commit Charge) while running a maximum app load. If it's 2GB or less, you're not likely to see a lot of performance improvement going to 64-bit.
>
>Windows will use any RAM not directly used by apps for a disk cache. If we take your current 4GB machine as an example, and suppose your app load peaks at 2GB RAM use:
>
>- 32-bit Windows can actually use somewhere between 3.0 and 3.5GB of RAM, depending on your hardware. Worst-case scenario, on your machine it can use 3.0GB, meaning it has a 1.0GB disk cache
>
>- 64-bit Windows will use the full 4GB (or more, if your motherboard supports it and you upgrade). This would give Windows a 2GB disk cache in the above scenario

As 64Bit code is slightly larger but more registers under 64Bit are available, 4GB would be "on the fence" for me. If 64Bit is the only OS, I'd install at least 8GB.

>You may say, well, the disk cache has doubled, that's going to improve performance a lot. That's not really the case - a cache is a good example of Pareto's Law, you get most of the benefit with not too many resources applied. For example, a 1GB cache may give 80% of the performance improvement you'd get with a 2GB cache.

One exception quite possible for users of this forum: It might be different if the app is is database app with where the table space is large.
We must stay with some of our longrunning tasks in 32 BIT, and realize different RAM size availability, as some of the machines can only adress 3GB, while others have 4 GB giving them 3.6GB usable RAM.

We are running vfp with 256MB, as sometimes run into errors with more memory given to vfp. I ran for kicks the app with a middle amount of data (about 12 GB) under 2GB of RAM on a normally 3Gig machine: runtime went up from 5H to 8H by decrassong disc cache size from 2.6GB to 1.6GB.

Yes, it falls under Pareto law - very astute observation - but the cost added from accessing not the cache is between 10 and 100 times the original cost. This is verified, as I have extensive time measurements with high performance counters throughout the application. Only a few operations on large tables take very much longer, resulting in substantial speed decrease.

@Matt:
My personal reccomondation would be to install a dual/multi boot. Once you get into the mindset of how to installl things (think unix:)
1..n parttion for 1..n OS,
1 Partition for Swap for all OS
1 Partition on a different drive from Swap for Tempdata
1 partition for installed apps
as many patritions for your data as you deem necessary and easily backupped

it even gives you some fallback position if you scramble one of your OS-partitions.
And get more RAM. It does not hurt...

>- many people treat the keyboard/mouse as a cheap afterthought. Most professional programmers have already settled on ones that work well for them. If you haven't, I'd urge trying out some ergo keyboards/mice. I personally love the Microsoft Natural split keyboards. They take about an hour to get used to, but you never want to go back.

While I have the MS split keyboards on most of the places I take my notebook regularly (including one in the car trunk...) I am really addicted to logitech ergonomic optical rodents giving offf a faint blue light. I prefer the tailed version, as batteries make the wireless less agile. I bought about 2 for every place I often work in case on breaks...

regards

thomas