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

Gleamed from howstuffworks

Invalid page fault - A program uses memory (RAM) to store data. For example,
when you load a document into Microsoft Word, large parts of the file you
are editing take up space in RAM. As the program needs memory, it requests
blocks of memory of specific sizes from the operating system. The program
remembers the location of each block it allocates using a "pointer." If the
program tries to write data to a location beyond the end of a memory block,
or if the program gets confused and tries to access a non-existent block of
memory using an invalid pointer, the operating system can see that happening
and generates a "page fault" or a "segmentation fault." The operating system
shuts down the program because the program obviously does not know what it
is doing.

"the program gets confused"

"The operating system shuts down the program because the program obviously
does not know what it is doing."

Made me laugh!



PS current status of my Solidworks
mem usage = 276,604
pauge faults = 201,930

Hmmm......

 

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

 

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