6 Replies Latest reply on Feb 13, 2018 8:17 AM by Jacob Corder

    Make a Macrofeature Comserver easier for solidworks to find

    Jacob Corder

      I am wondering if anyone could help me figure one thing out regarding macrofeatures.

      I have a comserver as a separate dll. It is written in VB.net and implements ISwComFeature.

      I separated it out of my addin to try to make it faster to instantiate for solidworks.


      I have a full design suite that automates tons of our work.

      The macrofeatures are direct representations of our machine shops tool library, they are sketchless. They guarantee a model that matches exactly what will be done after machining.


      So on to the question.

      I have a 500 feature block that rebuilds in roughly 9 seconds. The time my comserver takes to execute it's portion of the code is 3 seconds. Solidworks is taking 6 seconds.  I have found that alot of the time is spent finding my comserver through the registry.



      How can I make my comserver faster to be found for solidworks?


      I have added a key in solidworks xxxx macrofeatures but this didn't help much.  I see through process monitor(sysinternals) that it is calling alot of registry checks to get the comserver file name.

      I could add it to the GAC or add the comserver to the soldworks running folder to utilize Side-by-side.

      The problem is I have to move hundreds of thousands of lines of code which should be done anyway to put the dll in the solidworks running folder.


      Any suggestions would be helpful.


      This is basic com stuff here so any comserver registration optimizations will apply as solidworks is calling basic createobject stuff.

        • Re: Make a Macrofeature Comserver easier for solidworks to find
          Artem Taturevych

          Hi Jacob,


          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?




            • Re: Make a Macrofeature Comserver easier for solidworks to find
              Jacob Corder

              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

              Add Intersection time.  Time to create all split faces to create targets on each cavity. seen below. uses splitfaceonparam


              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.

                • Re: Make a Macrofeature Comserver easier for solidworks to find
                  Artem Taturevych

                  Hi Jacob,


                  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?




                    • Re: Make a Macrofeature Comserver easier for solidworks to find
                      Jacob Corder

                      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.

                      • Re: Make a Macrofeature Comserver easier for solidworks to find
                        Jacob Corder

                        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.

                        • Re: Make a Macrofeature Comserver easier for solidworks to find
                          Jacob Corder

                          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?