When testing or debugging code for an Inventor addin, I will often execute an external process that accesses the Inventor API. For an assembly containing 16000 nested components, simply traversing over each occurrence was taking 90 seconds.
Instead of calling ComponentOccurrence.SubOccurrences for each component, I found this time was reduced to 50 seconds if I only looked for occurrences within assemblies (i.e. first check that ComponentOccurrence.DefinitionDocumentType is DocumentTypeEnum.kAssemblyDocumentObject).
The execution time reduced to 8 seconds if I ran the code during the execute event handler for a button or change processor. I suspect this is due to API calls outside an event handler waiting for scheduled execution through the application message loop.
This is the F# code I used for testing.
let test (assembly : AssemblyDocument) = let rec loop (c : ComponentOccurrence) = if c.DefinitionDocumentType = DocumentTypeEnum.kAssemblyDocumentObject then for o in c.SubOccurrences do loop o
for o in assembly.ComponentDefinition.Occurrences do loop o
Timing
Without event handler and assembly check = 97.3 secs
Without event handler, with assembly check = 53.8 secs
With event handler, without assembly check = 20.1 secs
With event handler and assembly check = 8.5 secs
Now that the timing is more reasonable, I can continue with my intended performance test that compares repeatedly finding features in occurrences with finding a feature once and creating proxy features for other occurrences.
Regards,
cadull
Hi caddull,
Sorry, is that a question or a comment? I'm not sure what causes the performance difference, but this is an interesting thing to know. Thanks for sharing your findings.
If you are looking for performances, you should definitely use an in-process addin. We do not directly support F# as a language to create add-ins but I know this is doable. You could also have an external executable that connects to an in-process addin and control or exchange data with it:
Regards,
Philippe.
Hi Philippe,
I was just hoping it would prove useful to others in this situation. Your links demonstrate the solution if external initiation of Inventor actions is required in a live environment. In my case, it is a way of testing and debugging changes without needing to restart Inventor and reload a large assembly. Some loss of performance is an acceptable trade-off.
I've found that unloading an addin doesn't release the dll to allow changes. One option might be to dynamically load the dll from another addin so it can be released to make changes without restarting Inventor.
I currently rely on automation from a helper addin to perform actions that are impossible from an external process, such as accessing EdmSecurity.Instance or loading icons. My addin is written in C#, but it references an F# dll when beneficial.
Interestingly, the 8.5 second version of the code runs in 0.8 seconds in an addin.
Regards,
cadull