I have to write a function and am wondering which would be faster.
Using getimagesize() or storing the image size in a DB table and getting from there?
I acknowledge there are other factors to consider when writing an app. But I do need to know this, thanks.
I doubt getimagesize actually depends on the size of the image .. the width/height are usually stored as metadata which means only the image headers need to be processed. As such it should be a "relatively fast" operation and should take [mostly] constant wall clock time.
That being said, I'd tentatively lean toward a database call as being "faster" overall. (For the sake of arguments in my favor, I am projecting a non-bogged database on a low-latency connection with appropriate connection pooling and suitable schema/indices.)
The database has the potential for hotter buffers and slightly less IO. The dimension information is compacted over less bits and the database may be able to avoid additional system calls (getimagesize has to open the file each time).
Storing the dimensions in the database avoids duplicate image header processing. Even though I claim "relatively fast", the operation does take time which can add up over many calls.
If any other image metadata is accessed from a database then the dimension information could be trivially included as a "zero cost" addition.
Alternatively, a cache provider (e.g. memcached) could entirely blow away traditional RDBMS database performance for a simple association/fetch and could be backed with getimagesize as required.
As zerkms said, measuring the different approaches, in a real usage environment, is the only way to know which one is faster. There are factors that could tip the "performance" in favor of one approach over the other. Of course, it might not even matter: focus on making the slow 3% faster :)