Last modified: 2010-05-15 15:33:19 UTC
Currently image metadata is retrieved every time image apears on the page, so
file operations (file_exists, getimagesize) are called too often.
Image metadata cache can hold this information and reuse it every time when needed.
Created attachment 364 [details]
Changes in Image.php and SpecialUpload.php files
Changes in Image.php sets metadata to cache on first use an retrieves on next
Changes in SpecialUpload.php deletes metadata on image upload
We'll want to move metadata into the image tables for 1.5, but
this might be a helpful hack for 1.4 for the meantime. A few
If you can post diffs in -u format that'd be helpful; these are more
legible (including context) and are easier to apply to modified
Use tabs for indentation to keep consistency with existing code.
Memcached has a key length limit of 255 bytes; we have a title
limit of 255 bytes. A long image name thus may not fit; consider
using a hashed name in the key.
It might be best to explicitly support the shared image source
directory (commons); for instance by checking two memcached
keys (shared and local).
Does this interact correctly with generated thumbnails? What
about image deletions and reversions?
Remember to remove your test 'echo's before submitting patches.
The [$i++] stuff is somewhat opaque; consider using a dictionary.
($cachedValues = array( 'name' => $this->name, ... )
Created attachment 365 [details]
A better fix
Removed echos (shame for me for leaving those :), tabified, implemented cache
invalidation on delete/undelete/revert, better support of commons
(In reply to comment #2)
> Does this interact correctly with generated thumbnails? What
> about image deletions and reversions?
It does show thumbnails correctly, so I guess that it should not impact them
anyway (except that original image is not accessed for metadata retrieving).
However, there are few file_exists calls for thumbnails, but I'm not sure I know
enough about thumbnail lifetime to add some caching here.
This is committed to HEAD, it really should be backported to REL1_4. The
severity of this bug is "enhancement" but actually it's the major performance
problem in Wikipedia at the moment, apparently causing frequent timeouts.
(In reply to comment #5)
Set Version & Keywords accordingly.
Created attachment 369 [details]
Fix merged into 1.4 branch
Merger same fix (with Tim's adjustments) into 1.4 branch