For the 4th year in a row Adrian Fanjoy and I have done one of our favorite SolidWorks World presentations, "Allowing SolidWorks to Perform". The presentation was well received and we thought it would be a good idea to share the information with more than just the SolidWorks World attendees.
We will be publishing our presentation thru a series of blog articles so check back to the blog often to see what we have added to the series. We have also included a set of links at the bottom of this article that will take you to all past and future articles.
To get the series started we are starting with Who, What, When, Where, Why and How of putting together this information.
Introduction
From the standpoint of performance in a SolidWorks modeling environment; large assembly modeling is the most strenuous endeavor. As users of any CAD software can understand large assemblies can easily take a workstation to the limits of its capability. In working with several customers and from our past testing Adrian and I have determined many different means of improving performance for SolidWorks. This year we structured our testing a little differently so we could quantify the improvement and determine what improvement is worth the investment.
Our testing was different this year in that we were given a large assembly from Racine Railroad that we are now able to show. We also moved away from our benchmark macro to a custom built API that runs the model through many aspects of SolidWorks measuring our performance in a manner that has never before been done. In our tests we isolate individual changes in our hardware and modeling environment and measure the time difference of running the API against a Typical, Practical, and Optimal system. This allowed us to measure the effect of a single change and then compare that to other changes to determine where to invest time and resources to improve SolidWorks performance.
Please realize that the results that we are presenting in this document are specific to our environment, models, and tasks performed. While we are certain that you can expect similar results when making such changes, the magnitude of your performance increase will definitely be different than ours. When working with large assemblies the benefits that you realize may be more or less than ours. Overall you should see an improvement but realize that we cannot determine what other environments may hold, thus we will not guarantee the effect these changes will have in any environment other than ours.
Tests
To determine what changes make the most significant difference in hardware and modeling performance we ran our model through a custom SolidWorks API created by Bob Hanson (CATI/InFlow) that performed operations common in a typical designers day (ie. modeling, rotations, rebuilds, opens, closes, saves, etc...). We tested many specific aspects in the categories of hardware, system configuration, and modeling methodology.
Environment
To run tests of this nature and insure that the integrity of the testing was maintained we needed a system that was extremely adaptable. BOXX Technologies provided that workstation. The 3D BOXX 4920 Extreme Workstation gave us the ability to test a wide range of configurations without jumping from one workstation to another which would have made maintaining consistency in our configuration almost impossible. This ability to adapt allowed us to run tests that ranged from:
- 1 core to 6 cores
- 3.42GHz to 4.43GHz processor speeds
- 2GB to 32GB of RAM
- 5 different Nvidia graphics cards
- 5 different hard drive types
Model
Our model was given to us this year by Racine Railroad Products and was the ideal assembly to use for performance testing. It is a combination over 10,000 components with many layers of subassemblies that gave us the flexibility to perform all of our testing. The model, as seen below, is their Safelok Applicator & Remover, A.K.A. SAR Machine. The machine
both applies or removes the Safelok clip used mostly in concrete railroad tie scenarios; although there are wood tie applications as well.
The stats for this assembly are:
- 10559 total components
- 9693 parts
- 866 sub-assemblies
- 1292 top level mates
- 15093 bodies
In total the dataset takes up 1.92GB of disk space and has 4854 files.
Baseline or Typical Machine
For our baseline test we chose to run the API in a manner that we felt was consistent with typical environments that we see with customers and this will be referred to as our Typical Machine in all of our testing.
The core aspects (These never change)
- SolidWorks 2013 SP0
- WIN7 64bit OS
Hardware
- 1 - i7 processor with 2 cores @ 3.4GHz
- 8GB RAM
- OS and assembly storage on the same 7200RPM hard drive
Configuration
- SolidWorks options set to defaults
- Files are stored locally
- Several Add-Ins are turned on
- Operating system visual settings are set to default
Modeling methods
- Image quality set optimally
- High level of detail in some components
- Large number of top level mates
- Assembly is fully resolved
With our environment configured as above our benchmark ran in 4:43:44. Most of the comparisons that follow in our blog articles will be compared to this Typical machine.
In the subsequent articles in this series we are going to explore each test that we did. We will put the tests in no particular order with the exception of we will be posting all of our hardware tests followed by modeling tests. We will finish with 2 optimal configurations to see what the effect can be when you combine all of the improvements together into the same environment and model set. Occasionally we will veer off track and discuss a side topic here and there as well.
I hope you find these articles informative and helpful. Please
check back to the CATI blog as we will continue posting our
series of articles that goes further into the details of each of our tests. All
of these articles will be stored in the category of Free SolidWorks from Performance
Constraints and links to each with their
release date are listed below:
Thanks,
Josh
Altergott, CATI Support Manager
Adrian
Fanjoy, CATI Technical Services Director
