1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

V21 - API Performance

Discussion in 'General Discussion' started by simonb65, Jun 17, 2020.

  1. simonb65

    simonb65 Alibre Super User

    I thought I'd start this thread so I document performance issues that I now see when using V21 and an external application that hooks into Alibre using the API.

    The background is that I created a C# application some years ago which takes PCB design files and creates a PCB part, then using a library of electronic components that I've built over the years, it then creates an assembly and adds the PCB part plus the electronic component parts.

    I have used this application extensively with version prior to V21 and it generally creates a complete PCB assembly in no more than 3 or 4 minutes. Today, I tried it with V21 for the first time and it is sooooooo slow. After it adds approx 20 electronic parts to the assembly, Alibre hangs for about 10 minutes then recovers and the process continues until it hangs again for a while. At the end of the process my application saves the new assembly. At that point, Alibre has become unresponsive for over an hour now. Task manager shows ...


    I can't kill either the Home or Assembly Workspace task, yet it's still consuming approx 10% of CPU time and the memory is slowly creeping up.

    I'm not asking for comment as to why this is doing it, this is really a post for me to document my findings and share that so that others may benefit.

    I'm going to set up a known project (i.e. a specific PCB design), I'm going to fully profile my application in order to get some metrics, then I'm going to test that 'benchmark' on V21 HOOPS, V21 Legacy, and an earlier version of Alibre.

    I think it's important to determine if newer releases of Alibre are actually providing improved or worse performance. We see some many post on here on how certain functions are slower than they used to be or slower than other applications, so now it's impacted me, I'm determined to create a known benchmark that all versions can be tested against.

    Now, I know this is something that Alibre hopefully do internally, but anything I find will be given to Alibre to assist them. I will share the benchmark application with them in order that they can debug and improve performance.

    Watch this space!
    Drutort, GIOV, NateLiqGrav and 2 others like this.
  2. simonb65

    simonb65 Alibre Super User

    5 hrs later and Alibre is still unresponsive, task manager usage figures now, just look at that Memory usage since my first post! ...


    Time to reboot and start profiling some API calls!
  3. simonb65

    simonb65 Alibre Super User

    So, a simple benchmark test:

    V21 - HOOPS Mode ...

    1) Create a PCB Part (Single square sketch, extruded by 1.6mm).
    2) Save that Part.
    3) Create a new assembly
    4) Add the PCB Part
    5) Add an array of a simple electronic component part (single part, not a sub-assembly).
    6) Save the assembly.

    Test 1: Array of electronic components is 1x1 (i.e. total PCB + 1 part)
    Result :




    Total Test time 20.2s, Time to save assembly 0.98s.

    Test 2: Array of electronic components is 3x3 (i.e. total PCB + 9 parts)
    Result :


    Total Test time 11.2s, Time to save assembly 0.72s. Note: Less time to connect as Alibre process was already running.

    Test 3: Array of electronic components is 10x10 (i.e. total PCB + 100 parts)
    Result :


    Total Test time 31.4s, Time to save assembly 8.88s. Time to save has grown significantly compared to the time it took to create the assembly!

    Test 4: Array of electronic components is 15x15 (i.e. total PCB + 225 parts)
    Result :


    Total Test time 99.4s, Time to save assembly 43.25s. Time to save is now almost the same as creating the assembly.

    Test 5: Array of electronic components is 20x20 (i.e. total PCB + 400parts)
    Result :


    Total Test time 437.3s, Time to save assembly 324.87s. Time to save is now 3 times as long as it took to create the assembly (98.3s)! The assembly file size is only 210KB, so it's not the quantity of data to be written, it's how that data is being extracted from the internal geometry data structure.

    There is something fundamentally wrong with the performance and efficiency of the Assembly SaveAs function and it's changed dramatically in the last couple of versions of Alibre!

    Next test is to repeat the worse case here in Legacy mode, then to run it on an older version of Alibre. Then try suspend/resume UI calcs and even do this without showing the UI to see if the create times can be improved. Watch this space ...
    Drutort likes this.
  4. HaroldL

    HaroldL Alibre Super User

    Take a look in the Alibre.log file and see if there is an "out of memory" exception. I've seen that in some of my assemblies that take a long time to complete a task.
  5. simonb65

    simonb65 Alibre Super User

    V21 - Legacy Mode ...

    Test 5: Array of electronic components is 20x20 (i.e. total PCB + 400parts)

    Comparing this to Test 5 (HOOPS mode) in the last post...

    Total test time is less than half the time it takes in HOOPS mode!
    Assembly Creation is 25% quicker than in HOOPS mode!
    Save time is less than half the time it takes in HOOPS mode!

    HOOPS may be good for visual appearance, but it's NOT good for PRODUCTIVITY! ... and productivity is what feeds my family!

    More tests to follow ...
    GIOV likes this.
  6. simonb65

    simonb65 Alibre Super User

    Plenty of those ...


    That needs fixing to start with! Looks like resources are being created every time parts of the UI is drawn rather than using resource pools ... v.bad practice!

    Looks like the tree view (Design Explorer) is where that problem lies.
  7. simonb65

    simonb65 Alibre Super User

    Legacy Mode ... Interestingly, suspending Auto Regeneration during the Save, reduces the save time (all be it by very little!) ...

    Setting assembly.AutoRegenerate = false prior to adding parts to the assembly has no effect on the speed of assembly creation!!? ...

    Not sure what AutoRegenerate is intended to do within Alibre, but in my experience it has minimal or no effect.

    Hoops Mode ... previous test repeated ...

    Also setting AutoRegenerate=false has not improvemnt in Hoops mode.

    Next to try a No-UI approach to take that out of the equation ...
  8. DavidJ

    DavidJ Alibre Super User Staff Member

    Auto-regenerate (I believe, but it may be more complex) is mainly associated with multiple assembly configurations, to avoid some configurations getting left 'half cooked' by accident. So if your assembly doesn't have several configs, I wouldn't expect it to make much difference...
  9. NateLiqGrav

    NateLiqGrav Alibre Super User

    From the help:
  10. simonb65

    simonb65 Alibre Super User

    Thanks @DavidJ and @NateLiqGrav , Based on how Windows controls and UI elements suspend/resume worked, I was assuming that it was to control the normal process of recalculating between edits and that those calculation would be deferred until it was re-enabled (my bad). So armed with that, it is leading me to investigate other possible influences on the current performance times (hence the next step is to do the same test without the UI, i.e. UI less - background model processing, which should just process the model geometry without the render refresh mechanism), which is an option I believe I have seen in the API.
    Last edited: Jun 18, 2020
  11. simonb65

    simonb65 Alibre Super User

    Well, it looks like the method for creating a GUI less instance of Alibre doesn't work ...

    From the API Help ...


    So, implementing this in c# ...


    Create hook:

    Result when executed on v21.0.2.21034:

    Debug Output window:

    It gets as far as reporting the Product Version of Alibre and the current build number, then goes south!

    This was tested with no instance of Alibre running and also with Alibre running (Home Window showing). Both cases result in the same exception being thrown in alibre-executive.dll

    So, something in the new version does not like being invoked GUI less, even though the documentation says it's possible!

    @Max , has this been tested? Can you please confirm that GUI less functionality is still available in V21 and if so do you have a working example of its usage?

    Latest API documentation says that it is ...

    So for now, GUI less can't be tested, so time to install an earlier version of Alibre and test again...
    Last edited: Jun 18, 2020
  12. simonb65

    simonb65 Alibre Super User

    Well, after 2 1/2 hours re-writing the code that has worked for years to work GUI less (basically removing my exception handlers so that it didn't crash at the thousands of 'soft' exceptions the Alibre core dlls throw when running without a GUI!), I now have a repeat of :

    Test 5 in HOOPS mode ... With NO GUI ...


    Time to programatically create my 400 part assembly is about 25% faster than it was with a GUI in HOOPS Mode, and on-par with a GUI in Legacy mode.

    However, the save time is now down from 342s in HOOPS (120s in Legacy) to a staggering 0.6s in a NO GUI HOOPS !!!!!!!!!


    This is the kind of performance I would expect in either GUI or NO GUI. It raises the question as to what impact this may have during other save operations with large models, i.e. Not using the API. Unless the normal application process does not use the methods exposed to the API or is using a method that is not documented in the API documentation.

    Now for the exceptions raised with No GUI (they are not raised if you show the GUI) ...

    The Process of a new AutomationHook() call ...

    Saving a part:

    Adding Parts to an Assembly (this goes on for every part added, i.e. 400 in this test!):

    Terminating the AutomationHook using hook.Root.TerminateAll()
    This seems to be as the objects in the assembly parts are released/destroyed ...

    I'd rather see errors handled in the code than just throwing exceptions (which are time consuming to create and if not handled by the parent application, are time consuming to be processed by the default handler).

    These exceptions should not be seen by such a high level application, they should be handled gracefully well down the call stack.

    Good news is that with a few days of re-writing my code, my productivity tool will be back to where it was in an earlier version of Alibre, but it still doesn't answer the question why something that once worked well, has now degraded in subsequent releases.

    I will continue to profile both with and without GUI in future Alibre releases and share my findings.
    Drutort likes this.
  13. GIOV

    GIOV Senior Member

    Hi Simon,
    Very interesting study. Very professional. Although I am not an expert on the subject I suggest you try three old and three recent versions (as minimum) to check performance trend curves.
    Thanks for this initiative. I thing you are helping to Alibre Team to improve the software.
  14. NateLiqGrav

    NateLiqGrav Alibre Super User

    I KNOW for a fact that someone just did a find/replace for the version numbers. I checked checked for changes between this Alibre version and the previous version. I renamed the help files to .zip and unzipped everything in separate locations and compared them with WinMerge. After noticing a pattern of many files only having version numbers and copyright changes I did a batch replace using FNR for those two things and compared again. I'd say about 95% of the help pages that was all that changed in the help file.

Share This Page