ok i posted my specs
win xp sp3
4 gigs of ram installed
sw 2009 sp 5.0
parts are on the server
we do not use any pdm associated with solidworks
I assume your processor is good based on those specs... you should have no issue running SolidWorks with that. Do you have a lot of other apps open along with SolidWorks (like iTunes) Are you just getting a message from SW that says you are out of memory or have you actually watched your usage?
Any feel for the drain caused by a part with many configurations but only one or two are used in the assembly? Would you still vote for the configurations option? Or would you prefer a few different models inserted a few times.
my experience is if configs and design tables make sense for your parts then it is best to use them. For an assembly you are loading the part once with the active configuration(s) that are being used to load into memory (this is not as much of a deal with lightweight options from my understanding since it really only loads a "representation" of the body). If you had 15 bolts all in different files or 1 bolt part with 20 configs (15 being used) you are loading the same amount of data in the assembly (15 bolts). That is my understanding anyway...
side note: let alone the fact that you can swap out configs faster than parts due to internal references (especially if you have many hands in the cookie jar), it is more intuitive to use configs, design intent caries over from one config to another where seperate part files you can't do that... it all just makes more sense to use configs and design tables if you can in my opinion.
this thread has some details on the topic as well: https://forum.solidworks.com/message/47128#47128
can you tell us how large you assembly?
I assume that you are using 64bit operating system as you have 4GB of memory.
Do you have the /3Gb switch enabled? Are you working locally or across your network? If you're working across the network, try working locally and see if that helps. How big is your assembly?
There are a lot of things that can affect your system performance, beyond individual parts versus configurations. The more system information you provide, the better.
I was told the 3 gig switch was unstable and not recomended.
Yes i am on a network 1gb/sec
We use configurations for all of our raw materials. anything with a straight cut to length. So every length is a configuration and all sizes are new parts.
The main thing that I found with my extensive testing of the 3 Gb switch was that you needed to also add a uservalue of 2900 or so. When I took all of it, the system side eventually had problems so I kept backing off until I wasnt' getting system errors any more. 2900, 2800, 2700 - somewhere in there.
If you want to read more about it, go to http://www.kcswug.com/documents/ and grab the file 3gb_switch_part_one,_two,_&_three.pdf.
I've never used the 3GB Switch by my self, But I've seen a lot of people using it with out any problems. But it will better if you used X64 operating system.
As stated above, do you have a user value set?
The solution to the problem is to change to a 64 bit operating system. I was having exactly the same issues. I was running Windows XP Pro with 4GB installed and the 3GB switch and PAE on. SolidWorks would crash when it got just over 2GB of RAM usage on the software. SolidWorks was crashing on me about five times a day and saving took over a minute each time. Quite a lot of lost productivity there for certain.
If you want to know if you are truly hitting your hardware RAM limit run the Performance Monitor in Windows. You can find it in .../windows/system32/perfmon.exe. Clear all the "counter" items in the graph and add Memory>Pages Output/sec. This tells you how much of your RAM is being pushed onto the page file (virtual memory.) If it is running upwards of 96% or higher then your active memory usage is greater than your available installed RAM. When this happens the likelihood of SolidWorks crashing is very high. There some instances where SolidWorks does this regardless of how much RAM you have and that is a memory management issue that they need to resolve in the programming.
I have solved my problem by switching to 64-bit Windows 7 and SolidWorks 2010 64-bit. So far I have not had SolidWorks crash once. The system remains 4GB installed RAM and is cruising (with a complex exploded view assembly on a multi-view drawing and everything resolved) at 2.6GB used with 0% on the page file output.
... What is better, fewer parts and more configurations. or more parts and less configurations?
Others have expressed interesting opinions about hardware and OS configuration. I'd like to take a stab at addressing the philosophy of configurations vs. discrete parts.
The attached zip files (SW2008 format) compare 2 similar assemblies - one has a single (configured) part; the other assembly has discrete parts.
The spread sheet shows a file size comparison by including both the assembly and its associated part(s). In this example, the config version is 860kb, the discrete version is 4177kb - almost 5 times larger.
The circular array of config'd parts was easier to set up vs. all of the mates required for the discrete parts.
Creating the config'd part with a design table was easy and it made it convenient to set the colors for the various versions.
I find that creating a Propery Manager for configured components makes them easier to insert into assemblies by making it convenient to select the proper configuration at the time of insertion.
The discrete parts rebuild faster and if only a single size is needed in an assembly, the resulting file size is probably smaller.
The discrete part model is quicker to generate (unless several sizes are needed).
Depending upon the mix of parts, the discrete technique can reduce the burden on CPU cycles and address space.
So, the answer comes down to design intent.
For components like bolts, nuts, and washers I think configurations make a lot of sense. It cuts down on file count and makes choosing a different size a breeze.
If mulitple versions of the component are unlikely in an assembly (or project), then the overhead of a configuration paradigm may not confer any advantage.
I have been using 64 bit operating systems for more than a year and will probably never go back to a 32 bit address space. I would much rather focus on the product development vision than on the twiddly bits of the operating system.
Thanks for the info and the research. That settles it. CONFIGURATIONS!
Retrieving data ...