I don’t have measurment other than my game passing from not crashing to crashing. :)
C2 and C3 provide measurements specifically for this. I was suggesting that you look at them.
I didn’t mention it earlier, but another big problem I have using C3 instead of C2 is the huge performance drop... My theory about this is the following: Healer’s Quest sometimes needs to load very small images that are not present on the layout in the editor (they are too situational and there are too many of them to load them all on all layouts).
This forces a synchronous texture load and can easily cause jank in the C2 runtime. The C3 runtime actually loads textures asynchronously which should solve this problem (at the expense of possibly a couple of frames where the texture is invisible because it hasn't loaded yet - but avoiding the jank). As has always been the case, for best performance you must have every object that can be created in the layout initially placed in that layout, and destroyed on start of layout if need be; this means Construct will pre-load everything the layout uses and completely avoid any on-the-spot texture loads, which can hit performance no matter the size of image being loaded.
Then in C3 this becomes even more important, because it analyses the objects initially placed on layouts to identify the objects that are most commonly used together, and then groups them on the same spritesheet. This can lower memory usage by making sure the images on a spritesheet are always used at the same time, helping eliminate the case where you load a big spritesheet with lots of images that aren't used.
So this is a known case and has known workarounds. The jank from on-the-spot texture loads should be pretty much fixed in the C3 runtime thanks to its asynchronous loads, but even in the C2 runtime, if you do all of this it will make the performance even better than it was to begin with, since it won't even need to to on-the-spot texture loads even for small images.