An asset referenced by two Addressables groups gets packed into both

If an asset is not marked Addressable but is referenced by assets in two different groups, Addressables has no shared place to put it — so it packs a copy into each group’s bundle. Ten groups referencing the same font, atlas or material means ten copies in your shipped content. This is the single largest build-size finding in most Addressables projects, and it compounds quietly as the group layout grows.

What the scan looks at

PerfLint wraps Unity’s own Check Duplicate Bundle Dependencies analyze rule and aggregates the result per asset: how many groups pack a copy, which bundle files they land in, and the estimated waste. The aggregation is by group and bundle file, deliberately — collapsing by group alone hides same-group cross-bundle duplication, such as a per-scene-bundle group baking one font into each of 74 scene bundles.

What Unity already gives you

Worth being precise about this, because it changes what’s actually worth paying for. Unity ships:

• Addressables ▸ Analyze ▸ Check Duplicate Bundle Dependencies — finds the same duplicates.
• Build reports that let you inspect bundle contents.

What Unity doesn’t do is order the list by how much each duplicate costs, put the fix a click away, or verify the result. That triage and execution loop is what PerfLint adds — not the detection.

How to fix it by hand

The mechanism is simple: give the shared asset a home of its own.

1. Mark the asset Addressable and put it in a dedicated shared group. Once it has an address, groups reference it instead of copying it.
2. Set that group to pack separately if the shared assets are large and independently loaded — otherwise a single shared bundle is fine and usually better for load count.
3. Rebuild and re-run Analyze to confirm the duplicate is gone. Re-running is not optional: group layout changes can move duplication rather than remove it.

The trap to know about: some assets are multi-object (an FBX with meshes and materials, a sprite atlas). Analyze can report a duplicate that resolves differently once the parent is addressable, so verify per asset rather than fixing the whole list blind. The long version of that trap is here.

What PerfLint does about it

Findings are sorted by estimated waste, so the top of the list is where the megabytes are. Pro exposes an Extract to shared group action per asset: it marks the asset Addressable and moves it into a PerfLint Shared group — it adds the Addressable mark only, and changes no references, which is why it’s low risk. The confirmation states that plainly, and there’s a Tools ▸ PerfLint ▸ Revert “PerfLint Shared” Extraction menu to undo the whole extraction.

On a real project (a 1.3 GB museum build) working down this list cut content by about 38%; the full case study, with the before/after bundle report, is here.

After extraction

Extracting many small assets into a shared group can fragment your bundle layout — lots of tiny bundles, each with header overhead and a file handle. PerfLint reports that separately as ASSET.AAGRAN001 and names the dedup extraction as the cause when it was, so the two findings don’t appear to contradict each other.