In my previous post, I wrote I was optimizing my Texture Overview Unity plugin by caching texture properties (width, height, filesize, mipmap count, etc), that usually require expensive file I/O operations to collect. Once these properties have been collected, the plugin adds them to a persistent cache, so they can be served much faster the next time they are requested.
In order to detect if a cache-entry of a texture turned invalid, the plugin compares the AssetImporter.assetTimestamp to the timestamp of the cache-entry. If they don’t match, the cache-entry became invalid and the plugin has to read and collect the new texture properties, rather than just serving the cached data.
I was certain this solution will make the plugin blazingly fast, but to my suprise, it did not. It did improve the startup time of the plugin, but not as much as I thought it would be. The reason for that is AssetImporter.GetAtPath() can be horribly slow.
While the plugin starts, it calls AssetImporter.GetAtPath(“path”).assetTimestamp for every texture in the project, to detect if the cached data for a particular texture is invalid. During this time, the harddrive is extremely busy.
To try to understand what is happening there, I downloaded Process Monitor to monitor file system activity.
I created a little script that just calls AssetImporter.GetAtPath for “Assets/Textures/AngryBots.png” (inside the AngryBots project) and it turns out this inconsiderable method opens three different files, as Process Monitor reveals:
“AngryBots.png” is the source image file. “AngryBots.png.meta” is in Unity’s own words “a text file for every asset in the Assets directory containing the necessary bookkeeping information required by Unity” (see here) and “7b469925895d5466dbc74ebf68ae2a98” is the imported image file in Unity’s own texture asset format, the filename equals the asset guid you can get by calling AssetDatabase.AssetPathToGUID btw.
I’m wondering why Unity is actually opening all of these files. My understanding was the importer settings are stored in the .meta file, so why does it open the imported texture asset (two times) and why even the source .png file?!
I also noticed getting the importer for a huge texture file is slower than for a small one. I thought this makes no sense at all, but now, since I know Unity opens all of these files, this could actually be true.
Calling AssetImporter.GetAtPath a second time for “AngryBots.png” during the same Unity session, only opens “AngryBots.png” and “AngryBots.png.meta”, but not “7b469925895d5466dbc74ebf68ae2a98” anymore, so it’s much faster this time. I guess Unity loads the imported texture into memory and then it doesn’t need to load it again on the seconds call and this would actually support my theory that AssetImporter.GetAtPath performs worse the bigger the imported texture asset is.
Anyway, I will probably never find out why it is reading all these files and whatnot.
Unfortunalety, this performance issue makes AssetImporter.GetAtPath, to get my hands on the assetTimestamp, rather useless again. There has to be a way to get the assetTimestamp of 10000 assets in less than several minutes.