My list of attempted fixes:I am using G-data anti-virus. But turning off the virus monitor did not help.The uninstall of Norton anti-virus that shipped with the machine was perhaps not complete: Ran the removal tool they have on the Norton website and re-booted, did not help.In Eviews, modified the advanced system options/Multi-core use from "auto" to "3". Did not help.Tried the win7 control panel/system/performance and compatibility tool, no luck there either.

I realize this is likely not an Eviews issue, but perhaps someone has relevant experience.

That sounds odd. Without seeing what your batch programs do, it is hard to imagine what could be causing it. If they do lots of writing and reading of data from disk, then AV software might be to blame.

One simple thing to check - are you running your programs in verbose mode on the new computer, whereas your default was quite mode on the old?

Will try using the equation command instead of LS, to see if it has to do with LS showing the results on screen.Will also try it on my wife's new machine, which is using the same virus software, and also had Norton uninstalled.There are hints of other problems with the machine, so might be forced to back to original system point.

At this point the important question is whether I can expect a 64 bit version of Eviews in the next couple years. If not, then I will want the 32 bit version of win7 when I replace my office machine next year.

For the recordVersion of program which uses LS y x1 x2 command in the loop, so results are shown on the screen even in quiet mode:WinXp Service Pack 3, Intel Core2 Duo E8200 2.66 Ghz (about 3 years old): 9.32 seconds Win 7 Home Premium service pack 1, AMD FX-6100 3.3 Ghz (new a month ago): 18.47 seconds

Version of program which uses Equation eq1.LS y = c(1)*x1 +c(2)*x2, so no results show on screen in quiet mode:WinXP machine: 3.02 secondsWin7 machine: 2.51 seconds (15% less time)

There's not much doubt that XP screen draws are simpler than newer Vista/Win 7 screen draws and therefore faster, particularly if there's shading and transulcent window borders (the Aero interface). If you're working with short series (like 1000 observations) the screen draws can easily dominate any actual calculations you are performing.

A seond point is that AMD chips can be a little problematic for us because we use something called the Intel Math Kernel Library for some key calculations (matrix-vector and matrix-matrix multiplies) and Intel fine tunes this library for its own processors and doesn't necessarily play fair when it comes to running on AMD chips. (Many other applications also use this library which I'm afraid probably does tilt things in favor of Intel processors for math and statistical applications).

However, in your test program my best guess is that after screen draws the next most time consuming thing is the random number generation and this should perform equally well on an AMD chip. Many other parts of the EViews code will also run fine on AMD chips, it's just that some of the key routines like large matrix inner products may produce weaker performance than what the processor is actually capable of.