Question about memory usage optimization

Studio
#1

Suppose I have an image called “x”. I have 2 subsymbols called “z” and “w”. The parent of both subsymbols is “k”. There are 2 situations:

  1. I import “x” in “z” and “w” separately.
  2. I import “x” only in “k”, and reference it in “z” and “w”.

My question is this: Is there any difference between both situations in terms of memory usage? I always assumed that it’s best to follow situation 2 because situation 1 would double memory usage. But I’m wondering if my assumption is true. Does zapworks detect this internally and optimize to use just one reference to the image?

The reason I’m asking this is because it’s annoying to use situation 2, because if you go inside the subsymbol, you can’t see the image that is referenced in the parent. So it becomes hard to maintain when you want to make changes.

If Zapworks does not optimize situation 1, it would be nice to have access to global media files, so I can use these media files inside the subsymbol without referencing from the parent, so I can always see the image inside the subsymbol. That is not the only advantage, it’s about encapsulation and separation of concerns, so the subsymbol wouldn’t need to depend on the parent because of this.

I’d argue that it would be great if Zapworks could just optimize situation 1. Zapworks does know where all assets are referenced as you can check going to Analyze>Final download size…If Zapworks can just do this there wouldn’t be a need to implement global media file access.

#2

You can just go with situation 1, this is optimised when publishing. Media files are all deduplicated (filenames in the package come from their content hash) when publishing.

One caveat to be aware of - if you change a setting in the “Properties…” dialog on a media file, such as compression or encoding type, then you’ll need to make the same changes in the other places that file is used, otherwise there will be two different encodings of the same image in the package.

A global per-project media library would certainly help in some situations, for example easier updating of assets shared by many sub symbols, but it is a bit complex to implement (as it means symbols are not as self-contained any more, so exporting and sharing is more complex). It’s certainly something we’ll consider in future though.

1 Like
#3

@simon Thanks for clarifying this! Are 3d models also deduplicated when publishing? What about audio files and video files?

#4

Yup, applies to all media files. For longer videos we’d generally recommend streaming them in as either HLS or plain mp4 so they don’t slow down the initial download.

1 Like
#5

Ah this is awesome, I can just import the same model on all subsymbols? Wonderful!