Subassembly Composer Performence

[magnussvensson]

Hi
Great functionality improvements implemented in SAC2023 with variables as drop down and support to update used variables if variable is renamed.
This functionality have high impact on performance though.

A pkt file that opens and updates in minutes in SAC pre 2023 can take half an hour to open or update in SAC2023.

It would be great to be able to turn off the smart variables functionality and get the same or better performance as pre 2023.

Sac is going in the wrong way concerning speed, the slowness rebuilding the xaml file after each command is a pain and is frustrating if you want to build something a bit complex.
With the extra load added in sac 2023 makes the max size of a sa 10 times less then pre sac 2023.

Best regards /Magnus Svensson

[magnussvensson]

I think I found the performance problem, might be variables with multiple codes, ex. var1+","+var2.

It creates a list with 2 codes in one argument.


Ill get back after more tests.

[TimYarris]

Hi @magnussvensson,

Thank you for pointing this out. We have not seen a degradation in performance since adding the code and variable libraries. If you would please share an example PKT that demonstrates this in both versions, we will be happy to investigate.

[magnussvensson]

Hi Tim
I have shared an example to you as a one drive link.
Acceptable in SAC2021, impossible to open in SAC2023

Regards /Magnus

[magnussvensson]

@TimYarris 
Tested SAC 2025 for the first time yesterday and was stunned by the speed on opening and editing complex subassemblies.
I struggled with hours of opening time in previous releases and in 2025 I open the same subassemblies in seconds, great work.
I´m curious about what´s changed or fixed?
Is it the power of .Net8?  

Best regards /Magnus

[TimYarris]

Hi @magnussvensson .

I apologize for the very delayed response to this message. I'm really pleased to hear the great feedback about SAC performance. I asked Frank Huang, who has been leading implementation of our performance improvements, to reply to this message with details.

Shall we close this idea as Implemented?

[TimYarris]

Hi @magnussvensson,

I asked the team about what changed in SAC to improve performance. Apparently it's not related to the .NET migration. What we did update was how SAC processes PKT files with large numbers of decision nodes.

I hope that helps!

[magnussvensson]

Thanks @TimYarris 

Based on tests to just open a pkt file i SAC 2025, i would say that the idea is implemented.

[magnussvensson]

Thanks @TimYarris 

Based on tests to just open a pkt file i SAC 2025, i would say that the idea is implemented.

I will try to find out a best practice on how to build complex subassemblies with the new opportunities with SAC 2025.

[laurent.feuillade]

Hello @magnussvensson and @TimYarris ,

I am very interested in this discussion and the exchanges regarding the performance of Subassembly Composer.

I am also using Subassembly Composer 2025, but unfortunately, I have not noticed any significant improvement in speed. I would like to ensure that my working method is optimal.

For example, I created a complex subassembly, and once the PKT file is decompressed, the .xaml file is around 15 MB. This PKT contains a lot of work, but I wonder if this approach is still viable.

Indeed, it has now become very difficult to modify anything due to the software's slowness. For instance, it takes me about 2 minutes just to add a single point.

Should I consider adopting a different working method, or are there any optimizations that could improve the responsiveness?

Thank you in advance for your advice.