Do you mean that the actual instantiating of your macro feature take reasonable portion of time? What if you simply try to create 500 instances of your com server in, for example, VBA macro using the CreateObject and measure the time? Does it take more than 1 second in total?
And when you use process monitor, does it access the registry every time new feature created? every time it rebuilds or it is done once in the session?
Artem. Thanks for replying.
i have created my own program that creates my comserver 500 times and it does not report back any delays besides the initial creation.
i have done more research and solidworks is accessing the registry for each new feature and for each existing feature on file open. They must be keeping it in memory for each feature which would make sense.
What is driving me to assume there is a significant delay is I use Ants performance profiler and during rebuild it records my code exeecuting in just under half of the time to rebuild. also shown below is my own performace tracer.
Rebuild Time is the time from when MacroFeature:Regenerate is called and when MacroFeature:Regenerate has ended
Rebuild Dimensions is time to setup all Dimensions on all 537 features. there are between 5 and 8 dimensions for each feature
Memory Clear is time in GC. solidworks fix for idisplaydimensions crashing on rebuild. smh
Consume Check disregard
Create Body. Time to generate each tool body to be used to cut the body
Body Cut Time. time it takes to actually cut the body with the tool.
Start Time difference. The value between the end of Regenerate to the start of the next Regenerate
there are 0 features other than Macrofeatures on the block.
there is a huge time difference and it may be solidworks doing stuff on their end but its over half the time to execute rebuild. i am looking for any possible ways to make things faster. i basically cannot optimize my code much more.
here is a larger block
i dont know if it is finding my COMServer that is causing the delay, or if it is just solidworks gathering all the new faces.
on another note. all tool bodies are created using primitive body types with IModeler CreateBodyFromBox, CreateBodyFromCone, CreateBodyFromCylinder, IBody2:AddConstantFillets
when i execute GetEntitiesNeedUserID, i never receive any on these types of features. i only receive faces and edges when i create bodies from trimmed surfaces.
Thank you for the detailed explanation. I'm very impressed with your approach to troubleshoot this issue (looks like your performance tracer is a great tool).
May I ask you some questions
1) Are those macro features in a single part?
2) Have you tried to insert 500 similar native SOLIDWORKS features to measure the performance (like 500 of hole wizards)? From my experience SOLIDWORKS performance decreases exponentially when the number of features is growing, so perhaps this is just the way it is?
3) Based on the previous point can you try to insert all of these geometry manipulation within 1 feature. So 1 feature generates all of these 500 cuts and dimensions instead of 500 features generate 1 cut each?
4) Could you trace that there is no some sort of circular dependencies while regeneration, so each feature's regenerate method is called only once when rebuild is happening and there is not duplicate calls anywhere which may cause performance problems?
Yes. The features are all in a single part.
500 hole wizard features is about 100x slower than my macrofeatures. I will test tomorrow.
I can guarantee there aren't any duplicate calls. I have thought of this also before. The performance profiler counts the same as the feature count so that's good .
I will run all feature through the first feature tomorrow morning.
Thanks artem for your help. This has been plaguing me for years. I just want it faster.
A year or so ago I did discover a delay in pskernel.dll using just Trace. They disabled that program now so I can't recreate it.
Your probably right. The more features the longer it takes and it's definately not linear as you stated earlier.
So when I execute all cuts in one macrofeature, it actually takes longer. Seems like it has to do with solidworks body geometry. I saw create body take significantly longer as the tool bodies we're created. I also tried pre creating them using threading.task.parallel.foreach which oddly had an even slower creation.
So it seems that body count even temporary has a huge slowdown as more are made along with faces and efges. So it's probably just entity count that is causing the issue. I have rebuilt with minimum geometry(no fillets, or chamfers and no split faces and it does decreased my programs time to execute but not much on the delay call back to the next feature. It must be solidworks (pskernel.dll actually as I have recorded delays in that dll before) analyzing the body between calls to each feature. So probably not something I can change
One possibility is to write it in c++ maybe? Thoughts Artem Taturevych would this change anything?