We receive relatively small STEP files from our customers (between 100 and 400MB, 200 to 500 parts), but Solidworks has a lot of trouble opening them (SolidWorks 2017 SP05).
When I go to scratch the available resources, I see that Solidworks uses only 25% of the main processor, and 0% of the graphics processor! Same for RAM, the overall utilization never uses more than 75%.
It's a bit frustrating to have a decent machine (Xeon E5 @ 3.1GHz, quad-core, 8GB RAM), but to feel like you're not using it fully and struggling with the slightest file to open...
If anyone has an idea/suggestion to try to improve the situation, I'm all for it!
It's probably not a processor problem for a reason I've explained several times.
Native SW is not multitasking (is not multithreaded) so whether you are 1 or 12 cores it goes at the same speed. Only simulation is multi-threaded.
You can look in the twenty-doze task manager on the active core how many % it uses (only on one core).
And again, depending on how the conversion program is written, it's more or less long because it's far from being optimized because conversion is not a trivial thing.
On the other hand, if you have a lot of STEP to convert, it may be worth looking at the existing converters.
I continue the discussion a little because I moderately or do not agree with the conclusion.
pierricklancien says this """ I have already switched Solidworks to high priority, or even real time, but it doesn't improve things. """
We must not forget that everything is managed by the OS twentydose
We have seen that Solidworks does not multithread but the OS is multitasking .
The solution of declaring SW as a priority only tells the OS that if several programs (singletasking) are running at the same time, then it should be treated as a priority.
That said, this solution is old, i.e. before the arrival of multi-core processors. With multi-cores, it's the OS that dynamically decides which core will run which program. So you can very well run a program other than SW that uses multithreading. While running one or more single-tasking programs without significantly altering the single-tasking programs.
Let's go back to solidworks, if you run a conversion program and no other significant program (non-significant is e.g. looking at an intranet or extranet web page or doing Excel or other resource-saving program during the conversion).
The best way to prove what I'm explaining is to run the conversion on your own (without any other program running) and you'll see that your conversion program probably uses less than 25% of the processing capacity of a single core.
So if only one program is running, it doesn't need to be prioritized. If the conversion program is not efficient, well your 2CV will never be a Porch.
It is for this set of reasons, plus those I gave earlier, that Pierricklancien does not see any difference even after designating SW as a Priority.
in this case, it is SW that limits the CPU load, not windows. Priority or not, only program to work or not, SW is not able to use more than 1 CPU core.
with a 4-core CPU, it makes sense to cap at 25% CPU usage, which is actually 1 core that runs at 100% (and the others at 0%)
The hypothetical (and a bit bastard) solution would be to simultaneously launch 4 SW sessions (these will be 4 different tasks for windows), and to launch the opening/conversion of 4 STEP files (1 in each SW session) simultaneously.
In this case, if windows does its job well, each of the cores can be loaded to 100%.
it's worth the cost of testing
PS: none should be placed in "priority" in this case either, since once again, it's SW that limits to 1 core, not windows.
PPS: it is clear that the photoview360 module uses all cores, and up to 100%, during the entire duration of the rendering process.
PPPS: it will be concluded that:
For openness/calculation/design, it is the operating frequency of the processor that has the greatest impact on performance
For rendering calculations, it is the number of cores that has the most impact on performance
most SW users do not use photoview360, so multi-core is (today) almost useless on a machine used exclusively with SW
1°) You forget to say that the simulation module uses all the cores for the slightest simulation because this computing module does parallel computing.
2°) if you open several SW assignments you will get an error message because you will not have logging, nor automatic backup. You have to see the possible impact on the result (I've never tried).
I know that if you don't open two or more assignments, the assignments end up stepping on each other because they use the same files and during interactions and temporary updates. This causes a crash because SW manages memory very poorly .
3°) To say that SW does not use the possibilities of the multicore is inaccurate. The parts loading modules are in parallel calculation, which is interesting for large assemblies. There are other actions (SW programs) that occasionally use parallel computing.
The display uses multi-core. I have a 3D mouse and well if I run the ASM slowly or especially very quickly the assembly then it uses 3 cores at 100% or more than 3 cores.
You also have to look at the memory management which is not the same depending on the programs and the SW files loaded. Very important also disk interactions because this also plays a role since SW does a lot of memory swapping and especially disk swapping and this is even more true for conversion programs (which store a lot of intermediate results). Last point, the frequency of the processors varies according to the computational load and as said the memory usage.
On the other hand, for the GPU, it's dead calm.
So it is better to be careful when making conclusions (see your PP and PPPS) that may seem hasty or even inaccurate. It would be necessary to be able to have the detailed bench made by Solidworks to have the most detailed opinion possible.