....@suspicio - "Memory usage comparisons show static positions - not "performance drainage". As I said in my earlier post, idle stuff gets heaved out if there is insufficient physical RAM to hold everything in RAM, leaving the target application to run at normal performance."

Now this is where you have me a little confused. You refer to "static positions" & "idle". The stats I gave were in reference to Memory Usage, tallied in total by the Task Manager in the "Physical Memory" usage. Also, in relation to some of the heaviest hitters - media players, Firefox esp. - their memory usage is nothing further from static or idle. Now firstly, my understanding is that only "idle" processes will be heaved out of RAM, meaning if apps are chewing up the RAM, and are active not idle, then they won't be "heaved out" at all (without risk of crashing an app)... and there are only so many idle processes Windows can heave out to accommodate them. Secondly, if a x86 app is showing far more memory usage (both "working set" and "private working set") than a x64 equivalent, how does this not relate to usage of Physical Memory (or RAM)?? If system memory is being chewed up, does this not class as "resource drainage" as memory is part (not all, I know) of the core system resources?

I do come to computers primarily through a graphic/digital arts back-ground, so if this is one of those "black holes", do feel free to correct and clarify

Me, I'm an ancient IT professional with an obviously big gob/ego! I had the privilege of test driving Microsoft Windows v1 on an Apricot PC back in 1984. Later on we demonstrated to the RAF that Windows 3.0 could multi-program by running a number of program complilations simultaneously and showing the progress windows simultaneously scrolling.

I don't think you have a problem.

Kaninelupus has already advised that a lot of the HP crap can be removed and that will take a lot more of the *32 stuff with it.

You should also note that a 64-bit application will not use 32 bit processes.

A 32-bit application can spawn any number of *32 processes depending on service calls it makes to Windows. Adobe CS3, which you mentioned in post #8, is a 32-bit application and a whole load of *32 processes will immediately appear in Task Manager.

Unless I've misunderstood something, you don't have a problem.

If you can update to CS4, most (although strangely not Acrobat yet) now come with x64 - although will install both x86 and x64 due to some extensions not yet being updated for x64.

Also, are you using FileZilla client or server?? I ask because I know there are a few x64 FTP clients, but will have to did a little harder for free FTP server applications.

MS Office (easy enough to find Technical Preview) is x64, so another app coming up to move away from x86.

A pity you're running Vista not Win7, as with Vista heard quite a few issues running x64 WMP (due to numerous bugs DivX never sorted out), whereas in Win7, most codecs built in natively and running perfectly (not a single movie I haven't been able to play yet, an believe me, have several hundred GB of movies of various encodings) and not a single hitch yet. Would be interesting to compare x64 FLV to x64 WMP12 to see what difference there really is.

Rather than simply relying on Task Manager to keep tabs of x86 apps and memory/resource usage, use this tool, as will also list all the core processes being called up as a result... gives a little more perspective, and very useful.


@suspicio - "Memory usage comparisons show static positions - not "performance drainage". As I said in my earlier post, idle stuff gets heaved out if there is insufficient physical RAM to hold everything in RAM, leaving the target application to run at normal performance."

Now this is where you have me a little confused. You refer to "static positions" & "idle". The stats I gave were in reference to Memory Usage, tallied in total by the Task Manager in the "Physical Memory" usage. Also, in relation to some of the heaviest hitters - media players, Firefox esp. - their memory usage is nothing further from static or idle. Now firstly, my understanding is that only "idle" processes will be heaved out of RAM, meaning if apps are chewing up the RAM, and are active not idle, then they won't be "heaved out" at all (without risk of crashing an app)... and there are only so many idle processes Windows can heave out to accommodate them. Secondly, if a x86 app is showing far more memory usage (both "working set" and "private working set") than a x64 equivalent, how does this not relate to usage of Physical Memory (or RAM)?? If system memory is being chewed up, does this not class as "resource drainage" as memory is part (not all, I know) of the core system resources?

I do come to computers primarily through a graphic/digital arts back-ground, so if this is one of those "black holes", do feel free to correct and clarify

For a non-IT background, you have picked up a heck of a lot that enables you to give sound advice - IMHO at least. Also it is damn useful to have a graphical arts computer expert on the forum.
!

For a non-IT background, you have picked up a heck of a lot that enables you to give sound advice - IMHO at least. Also it is damn useful to have a graphical arts computer expert on the forum.

Me, I'm an ancient IT professional with an obviously big gob/ego! I had the privilege of test driving Microsoft Windows v1 on an Apricot PC back in 1984. Later on we demonstrated to the RAF that Windows 3.0 could multi-program by running a number of program complilations simultaneously and showing the progress windows simultaneously scrolling.

Anyway, back to the VM and *32 issue. "Performance drainage" would ordinarily be taken to be dynamnic in nature. Things are running but more slowly than in other circumstances.

Memory usage figures are a static snapshot. When a single application is running (ignoring for the sake of this discussion background process that may intrude from time to time), it acquires all the memory resources it needs, heaving out (rolling out) idle processes according to an algorithm (such as least used).

The only consideration then is whether or not the amount of physical RAM you have is sufficient for the most demanding application that you might have (or in this case BskiLLs).

So, taking the example of the dynamic expansion of RAM usage by Firefox, idle stuff will be overwritten or heaved out (if there is data to preserve). If you need more RAM than you actually have, your own processes will be heaved in and out or overwritten and brought back in. The answer thare in an x64 OS is to add physical RAM if you feel that the application is suffering from the memory management overheads.

You then mention "resource draining" in the sense of equating it with "performance drainage". That has always been my point in this discussion. "Resource drainage" can be overcome by adding resources. "Performance drainage" can usually be managed by doing less concurrently or by upping processor power.

Increasing RAM increases performance, of course, because there is less time spent heaving stuff in and out.

I think that at this point, we probably converge!

Oh, a hint with Adoebe updates... the updater NEEDS to run as Admin (set through properties window) unless the UAC is set right down low.

Go to C:\Program Files (x86)\Common Files\Adobe\Updater6, set both Adobe_Updater.exe and AdobeUpdaterInstallMgr.exe to run as Admin (set for all users). This is just due to the fact that Windows file protection prevents from running otherwise... holds true for a number of application updaters



True, but given that many end-users expect to pay $500-600 for a computer and then be able to watch all their HD movies, and open a g'zillion tabs in their browser, streaming YouTube and the likes, filesharing and mobile-phone tools.... as well as having a "pretty" computer OS, RAM and Vid card specs HAD to go up just to keep up with it... not to mention running all the extra crapware the OEMs are forever throwing in!