I have an issue where, I’m not sure what changed, my .TOE file jumped in size by 30x, and as a consequence, saving and loading of the file is super slow. How can I debug what is taking up the storage size? What about .TOE save and load times?
This was a critical bug we discovered in 2019.18360 and 2019.30550(experimental) where bad data was being saved in parameters. We have fixed it and pulled those builds replacing them with 2019.18580 and 2019.30790 respectively.
Opening your .toe file in these new builds should fix your troubled .toe file, but if you still have a problem with it please send it to support and we’ll clean out the bad data.
Sorry for the inconvenience.
I don’t think it had to do with a version, as I’ve downloaded the preview release that went out today and the issue still occurs. Is there a way to see how much storage is in each component? That would really help debug these issues ourselves.
I’m concerned that by the time it takes to send the TOE and to get it back our original TOE file will have changed to due active development, and switching to the other will be a challenge.
Ok, just talked to the programmers and 30790 no longer has the growing .toe file bug BUT it was not automatically fixing the corrupt .toe file size. This build here will fix the file size if that was the problem, and if you were using 30550 at all it is a very high chance that was the issue.
dropbox.com/s/6inhfzxujl1q0 … 0.exe?dl=0
The other way you commonly see a .toe file getting large is if you are locking operators using the Lock Flag, as that locks the data into the .toe file.
If you still have issues, if you can send us your file we’ll turn it around instantly, you won’t need to wait long 
Is there a way to search for locked operators? Or a way to list the cache sizes of these locked operators? I’m finding this problem too, and it would be useful to see where in the network the file size is building up.
I found mine, it was a locked SOP