topic Re: Implications of assembly recomputing to collaborative work in Fusion Design, Validate & Document Forum

Implications of assembly recomputing to collaborative work

aleksei_ovsienko — Thu, 28 May 2026 14:27:13 GMT

The way Fusion handles assemblies means that whenever a component of the assembly is changed and saved, to see the change in the assembly that consumes it one has to "Get Latest" which causes the recompute of the entire assembly, probably by pulling all latest versions from the server and rebuilding all joints and relations.

This recompute is extremely slow which has been highlighted many times and every update they try to make it perform faster. But I do not believe this is a solution.

Whenever a team works on a large project different members of the team work on different parts of design but they all tend to keep the top level product assembly open for references. They can not all work in its context with Edit In Place at the same time, but they can each work on their part and Get Latest to see if the change they made to subassemblies and components fit.

This means that all members of design team run Get Latest dozens of times a day. This works at first. But as soon as you get to the top level assembly it is just unbearably slow. Our product assembly currently take more time to recompute than it takes me to write this post. It is not something that can be solved by making it 10-25-50% faster. Its fundamentally done the wrong way, because the assembly we're working on isn't even particularly complicated or large. I could understand such problems in designing an airplane or a spaceship.

But the assembly should not take 10 minutes to recompute just because it has a couple hundred joints in it.

This just isn't the way.

How do other systems solve this issue of collaboration? Again my past experience is with Creo. The way Creo handles this is every member of the team works in his own local session that run in the local memory. That session is loaded not directly from the server, but from his personal online workspace. The user uploads things he wants to work on into his workspace. From there they load onto his machine. Saving something requires checking something out for changes first, then saving it locally, then uploading it to workspace, then checking it in to the server.
This is designed so that every member of the team has everything he needs running locally on his machine, all changes one makes are automatically implemented in the local session. No "Get Latest" all the time. It updates live, you save in one window, it updates in the assembly in another instantly. It doesn't recompute for 10 minutes. Technically every user works on a different model in his workspace and in his session. They only synchronize their work when they check things in and update their workspaces and session. But this doesn't need to happen often.

Now imagine someone needs to design an airplane in Fusion? How would one even go about it? It just won't work. With such large assemblies teams need to re-compute them no more frequent than once a 24-hour period, probably at night.

I used to think Creo way was complicated and confusing. Now I understand the alternative. "Get Latest" and go have a tea. Make a small change to a part, get latest and go have lunch. Fix a small mistake in thread engagement on the baseplate, get latest and go write a post on the forum. Why do you think I'm so active here? Need something to do waiting for my assembly to recompute, praying it doesn't crash. I think it just about finished...

Re: Implications of assembly recomputing to collaborative work

raymondxu — Fri, 29 May 2026 03:17:48 GMT

Thank you for sharing workflow performance with us. @aleksei_ovsienko

In Fusion, the terminology has evolved over time. What was previously referred to as Version/Milestone is now termed Change/Version, depending on whether the hub is legacy or migrated. For clarity, I will use Change/Version to describe the workflow.

My understanding is that sub-assemblies can be effectively managed through Versions. In practice, a team may introduce multiple Changes throughout the day but only define a new Version at the end of the day. The top-level assembly would then consume these finalized sub-assembly Versions, rather than each incremental Change. This approach would reduce the need to execute “Get Latest” operations multiple times during the day.

Would this approach address your scenario? Please let me know if I have misunderstood your requirements or pain points.

We are also aware that the “Get Latest” operation can be slow for large assemblies. The team is actively working on performance optimizations in this area. If you have a case where the operation takes approximately 10 minutes and are willing to share the dataset, we would appreciate the opportunity to investigate further and identify potential improvements.

Re: Implications of assembly recomputing to collaborative work

aleksei_ovsienko — Fri, 29 May 2026 07:59:30 GMT

I can see how that approach may work for some tasks. But in a case where you need to design something on the top level it falls flat. There will inevitably be hundreds of joints in any top level assembly as subassemblies and parts need to come together, be fastened, have harnesses and cables routed through numerous tie-down points, etc etc. In the densely populated assembly you need to adjust parts in subassemblies to make up space further on the top level. In short there's lots of design work at the top level that needs more or less real time updates.

The main issue is that Fusion seems to experience huge issues re-computing and updating assemblies way before any other system. I used to have Creo assemblies designed for configuring hundreds of design versions based off of them with no issue whatsoever. It took a minute to open up initially and then worked updating live instantly throughout the day. You can expect similar problems in Creo if you've got a Lockheed Martin design bureau building an airplane. Then they'd use a number of special tools Creo has to lighten the top level render (like they turn would off the rendering of all fasteners, chamfers and fillets and other features for some subassemblies), then they'd set it to re-compute overnight.
But we're just two guys making a battery system. A large and complex one, but still it's not going to space. And I've already tried some of those dark arts like moving fasteners to a faux subassembly, because otherwise the model just wouldn't work at all.

I'll PM you the link with the dataset.

On a sidenote we also have a weird problem happen that we can't figure out. We have 15 subassembly "Module" inserted in the top level assembly. Some of them are fine, on others one of the components randomly changes position. The Module subassembly has been checked and its perfectly alright and all parts in it are constrained and all. But then in the top level - some modules are OK, and others have parts all over the place. This happened on other subassemblies before and I used to fix it by removing the affected assemblies and re-inserting them. But now I can't do it because it's so far upstream in the timeline that it will make everything downstream fall apart and just re-constraining doesn't fix it. We're now trying to re-constrain it off of a different reference but it takes ages because of the assembly size. Every operation on it just takes ages.

Re: Implications of assembly recomputing to collaborative work

aleksei_ovsienko — Fri, 29 May 2026 09:16:49 GMT

I think I identified the source of the trouble. It may be some conflicts in one of the large subassemblies that's causing this.

Update: Yeah. It looks like we finally managed to fix the worst of it. The problem was that a rather complex subassembly way upstream the timeline had issues in it that made it extremely slow to load. That in turn slowed down the top level. It's now back to manageable.

Re: Implications of assembly recomputing to collaborative work

raymondxu — Fri, 29 May 2026 13:02:25 GMT

Thanks for the update @aleksei_ovsienko .

Well noted. Just let you know Fusion team is proactively working on performance improvements. If you still see performance problems, feel free sending me your datasets. I am happy to look into them.

Re: Implications of assembly recomputing to collaborative work

TrippyLighting — Fri, 29 May 2026 15:31:44 GMT

@aleksei_ovsienko wrote:

I think I identified the source of the trouble. It may be some conflicts in one of the large subassemblies that's causing this.

Update: Yeah. It looks like we finally managed to fix the worst of it. The problem was that a rather complex subassembly way upstream the timeline had issues in it that made it extremely slow to load. That in turn slowed down the top level. It's now back to manageable.

I'd be interested in hearing how you found/identified these issues.

As I've pointed out in another of your threads, if you place hundreds of individual fasteners with individual joints, regardless of whether they are coming from the fastener library or not, your recompute times will go through the roof!
The main difference between Fusion and most other CAD systems is that joints and constraints are recorded in the timeline, resulting in slow recomputation.
The ONLY reason joints are recorded in the timeline (often along with a position capture feature) is to enable position-based modeling. I don't use position-based modeling, so it would be incredibly helpful to have an option to turn it off and NOT record every joint and constraint in the timeline.

Re: Implications of assembly recomputing to collaborative work

TrippyLighting — Fri, 29 May 2026 16:55:08 GMT

Is there any documentation, or are there comprehensive tutorials available that explain the functionality in depth?

It seems that Autodesk leaves user education almost exclusively to YouTube influencers. Unfortunately, that is completely mixed back in terms of quality and depth of content.

Re: Implications of assembly recomputing to collaborative work

aleksei_ovsienko — Mon, 01 Jun 2026 08:23:34 GMT

So basically in desperation I gave up on the assembly that was too slow and tried starting a new assembly in direct modeling with no timeline to see if it will work faster. And the first subassembly I tried to place in was incredibly slow and refused to even be properly constrained. That led me to believe there was something wrong with it that was in turn slowing the top level assembly. So I went into it and indeed it was sloppily put together in a few ways, with broken contexts around and rigid groups and hidden parts that were referenced in contexts, etc. So I went through its entire timeline to rebuild it properly and get rid of all that junk. And once I've done that it started running smoothly and my main assembly also unfroze a little bit. Which in turn allowed us to go through the main assembly and clean that up from things like contexts. And now it runs a bit slowish but not catastrophically so. We can live with it.

Although the immediate issue is resolved, the assembly is still sluggish. Which leads me to conclusion that if we were to attempt to design anything larger we'd still be up Schits Creek without a paddle.

When you design stuff, more so when you design stuff in a hurry, you inevitably end up modelling rather sloppily. I try to maintain discipline - for example I take care to always break link and delete all contexts in the parts and to have everything independently constrained and dimensioned just to not create a mess of circular references. But people in a rush will inevitably model by the seat of their pants, get that one part out for quote and then come back to the assembly and ask themselves "How do I fix this mess?" They should have the tools to do it available to them.

Suggestions:

1. @raymondxu Please improve "Replace component" tool. In its current state if you replace anything all its references and all references to it go out the window. And even if you remake the joint/constraint that hold that component in place, everything else downstream of it falls apart. A tool is needed that would allow to carefully re-select all relevant references. I've raised this issue before. Look up how other CADs handle it. Creo allows one to replace one component with a completely unrelated one by prompting the user to substitute all references one by one. It shows you both models side by side, lists the references, you select them and the part is swapped without anything downstream falling apart.

This is very important to be able to fix things. Right now the Replace component tool is essentially useless. And the only alternatives to this tool are suffering or using master geometries/sketches to assemble everything. Master geometries, however classy an approach it is, are a rather niche technique for huge collaboration projects (again think Lockheed space rockets), not for your average design engineer.
I can do a lot with Claude Code but I found that manipulating existing references in Fusion is pretty hard, especially with Constraint feature, so I'm not sure I can vibe code my way out myself.

2. Would be nice to be able to switch off all preview animations or better yet - have them on demand. In a large assembly a preview animation of a joint takes ages to compute and half the time I don't want to see it, just place the thing.
Worst of all is Duplicate with joints, as I mentioned in another topic. It wants to recompute all previous joints in the preview before it computes the next instance. On washer 201 it takes ages. I vibe coded a tool to do it another way - https://github.com/Danecca-Ltd/FusionBatchInsert . I made preview optional so that if you need to place 200 washers you can skip the preview and just have them placed all at once. If we could do the same with all other animations of things flying into place - that'd be grand.

Re: Implications of assembly recomputing to collaborative work

TrippyLighting — Mon, 01 Jun 2026 11:23:56 GMT

I agree with your suggestions! More than any other current user here on the forum, your suggestions are on-point! Please keep posting!

The replace command, indeed is useless in it's current implementation and I've discovered and reported a bug when replacing assemblies.

One thing that caught my eye is this statement:

@aleksei_ovsienko wrote:

...

When you design stuff, more so when you design stuff in a hurry, you inevitably end up modelling rather sloppily. I try to maintain discipline ...

We all try to maintain discipline, but in day-to-day operations under time pressure s**t happens. Even with decades of professional engineering and CAD experience I still make mistakes. Fusion provides ever more tools to create complexity, but the tools to manage that complexity, to fix mistakes, are far behind the rest of Fusion.

Re: Implications of assembly recomputing to collaborative work

raymondxu — Wed, 03 Jun 2026 03:31:54 GMT

Thank you for feedback. @aleksei_ovsienko I will forward your feedback to replace component feature team.