Skip to content

Conversation

@lefth
Copy link

@lefth lefth commented Sep 20, 2019

This fixes #129 by using a profiler API call to check how large each asset will be after import. For assets that aren't supported, it falls back to the old method of checking the size on disk.

Something to be aware of: the size shown is a size in memory rather than a size in the asset bundle. So an audio clip which is decompressed upon loading will have a large size shown.

@alffanclub
Copy link
Contributor

GetRuntimeMemorySizeLong does not show the in-bundle size. It's the in-memory size of a loaded bundle. In some instances it's more accurate than the on-disk, in some not. Perhaps in many it's more accurate.
The problem is that it's far more costly to calculate. All assets need to have LoadMainAssetAtPath called on them. This can significantly affect processing time.

@FWCorey
Copy link

FWCorey commented May 3, 2020

Should probably show multiple sizes when an item is selected. Fast size by default.

@patrickdevarney
Copy link

I was looking for a similar change in behavior and tested this out. At the very least, this does not work well for texture sizes if texture streaming is enabled. We have 1MB textures in the project, which are compressed to 85.4KB for our target platform, but GetRuntimeMemorySizeLong returns ~1KB for all these textures (might be the size of the smallest mipmap).

Still searching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Asset sizes should be shown as imported sizes, not on-disk sizes

4 participants