Could this be why solidworks is sooooo slow.....

Very funny :)

Maybe not. Page faults are normal. but excessive page faults are an indicator that there is not enough memory in the system. In other words, a lot of page faults mean you're thrashing the hard drive. That does mean you're running unnecessarily slow.

_invalid_ page faults slow things quite a bit more.

Pagefaults have been around since the early days of computing (think massive IBM mainframes in air conditioned rooms with raised floors and small substations outside to provide power). The computer is simply doing what you and I do in everyday life. When we are done with something we slip it into a manila folder and alphabetize it in our file drawer for later use. That way only what is necessary is on our desk. Computers do the same thing using fancy algorithms to make it more efficient. Disasters happen when a page is put back in the wrong place or can't be found or many other scenarios. As Dale mentioned, to many pagefaults mean the desk (memory) is too small to hold what is needed at the moment.

AMD came out with a neat little trick to help with this called Physical Address Extension or PAE. You know it as DEP in XP. This allows Windows or any other OS like Mac or Linux to put non-executable data in memory above 4GB on a 32bit system.

On XP, in the boot.ini file if you have this: /PAE. However, don't mess with this unless you read up on it on MicroSofts website. Not all drivers support PAE and I havent determined whether SW has enabled it in their software. The benefit of having it is to allow the OS to find a little more room in memory to stash data. Hardware, drivers and software all have to support this.

TOP

Hi Dale

Going by:-

PS current status of my Solidworks

I have 4Gb ram running with a amd x2 4800 and xp pro

Looking at the figures, there is more than enough spare ram. Or do I need to look elsewhere?

Back when I got this machine, I experimented with all kinds of boot switches to try to coax any improvement out of it. That's when I determined that

2900 was the user value that worked the best for me on the average. I also tried the PAE switch and it didn't seem to make any difference.

WT

/PAE may not have made a difference because it was already enabled. Windows defaults to having it on as part of DEP. If your hardware supported that it would have been on already. You would have to turn it off to see a difference. Where this may matter is on a system that doesn't have support for this in it's drivers or hardware. It may make things more stable. I am trying to test this hypothesis.

TOP

"pete" wrote in news:f6vdb0$2gh$ snipped-for-privacy@news.freedomsurf.net:

Well, that's as far as you can go with 32 bit Windows. Most likely, you are not having "excessive" page faults. Out of memory errors would be the wall you would hit.

Pete,

I just created an example of what happens when paging gets in the way. There is no way the numbers you posted indicate that. I'll have to mail it to you. Using Google send me your email address.

Paging is a good thing. It means the slackers are getting out of the way of the doers. :)

For the rest, what you look for with page faults is the Task manager performance window. Watch RAM usage grow and then all of a sudden CPU will drop to a fraction of what it was as memory grows past physical memory. When that happens performance goes through the floor.

I looked at some other things regarding performance also. It is really hard to say what makes SW slow other than it is. It doesn't hit cache much. About 11% misdirected branches and about 2 cycles per instruction on my Barton. There are just more instructions to execute than we have time for.

TOP

I can send you a screen grab, where Solidworks has a peak mem usage of

178,020 and a page fault of 115,249, whilst at the same time, swBOengine has a peak mem usage of 49,268 and a hugh 10,014,877 page faults!

You will have to explain how to use google to send you my email address

Pete,

You picked a good example of why page files are good. swBOengine is supposed to stay in the background. So every time a memory hog like SW is running swBOenginer pages out to disk. Hence, the monstrous paging. It is gracefully yielding precious RAM to SW and the OS while still remaining active.

SW paging might be due to data (if a very large assembly) or to parts of the code taking a back seat to active RAM usage. Page faults only become a problem when they become the limiting factor to keeping the CPU pipelines full with data and code. The numbers you are posting don't tell the whole story. For that you have to have CPU utilization and page file usage data versus time.

To send an email log onto Google and this NG. Then reply to author.

TOP