That logic is flawed. (me almost speaking Vulcan
)
A test like that is not representative for anything; it gives a vague idea for one thing that was already known by anybody that deals with graphics. Dismissing an idea based on this would be just like me saying today it's a rainy day over here, that's why this is not gonna fly.
I would understand if somebody from the devteam comes and say "yo', we've run our metrics, here's the numbers - it totally kills the experience"; or say "hey this might be doable but it requires a lot of time and effort that right now we are channeling towards other goals". That would be sensible reasoning for anybody that works in the real world.
Speculating from the sidelines (which is the best I can do):
- MC already deals with tens, maybe hundreds of thousands of thumbnails for its databases. Even with the awesome compression of JPG it should've gone haywire long time ago. It is the magic of their engine that deals with this which I'd venture a guess that it's optimized for dealing with binaries (pictures), since a normal database doesn't store binaries.
- considering only size of things it's dangerously simplistic when it comes to databases. There's also I/O, multithread reading, specific optimizations, etc that affects the responsiveness. Of course I would not ask this to be changed just to accommodate my request, I'm just saying there's a bigger picture out there, not just one thing.
- keep in mind the alternative solution I mentioned above (overlay) that doesn't touch the databases at all.