Significant performance enhancement for ASIDownloadCache's -clearCachedResponsesForStoragePolicy: #347

Open
wants to merge 5 commits into
from

1 participant

@revetkn

Instead of walking each file and deleting it on the current thread, we move the cache directory to a uniquely-named directory in the temp directory and delete its contents on a background thread. For whatever reason the iOS filesystem can perform a rename very quickly but deletes - especially for larger files, e.g. images - can be very slow (orders of magnitude slower) on old devices like the iPad 1.

This approach should be safe even if the background deletion thread is unable to complete normally (e.g. the application is unexpected terminated during execution) because we can rely on the system to clean up for us eventually since we're operating on files in the temp directory.

ASIHTTPRequest is a great library and I have used it to build some high-traffic apps. Unfortunately I was really bitten by the cache-clearing performance on older devices. Users were unable to start up the app due to being killed by the iOS watchdog since the deletes took so long to execute. In our app, this call might have taken 20 seconds in the pathological case (!) on an iPad 1. Now it takes about 100ms.

Another way to address this would be to allow client code to specify ASIDownloadCache size/item limits, with some kind of LRU eviction. But this was a quicker, less invasive win for me.

revetkn added some commits Nov 19, 2012
@revetkn revetkn Significant performance enhancement for -clearCachedResponsesForStora…
…gePolicy:

Instead of walking each file and deleting it on the current thread, we move the cache directory to a uniquely-named directory in the temp directory and delete its contents on a background thread.  For whatever reason the iOS filesystem can perform a rename very quickly but deletes - especially for larger files, e.g. images - can be very slow (orders of magnitude slower) on old devices like the iPad 1.

This approach should be safe even if the background deletion thread is unable to complete normally (e.g. the application is unexpected terminated during execution) because we can rely on the system to clean up for us eventually since we're operating on files in the temp directory.

ASIHTTPRequest is a great library and I have used it to build some high-traffic apps.  Unfortunately I was really bitten by the cache-clearing performance on older devices.  Users were unable to start up the app due to being killed by the iOS watchdog since the deletes took so long to execute.  In our app, this call might have taken 20 seconds in the pathological case (!) on an iPad 1.  Now it takes about 100ms.

Another way to address this would be to allow client code to specify ASIDownloadCache size/item limits, with some kind of LRU eviction.  But this was a quicker, less invasive win for me.
9aadd7c
@revetkn revetkn NSStreamEventErrorOccurred -> NSStreamStatusError fix 93ca247
@revetkn revetkn Deprecated NSDate -addTimeInterval: replaced with -dateByAddingTimeIn…
…terval:
3a1eac4
@revetkn revetkn Fix for deprecated methods 7cf10bf
@revetkn revetkn Comment out deprecated "ignore invalid certs" code since we don't use…
… it anyway
14d10ce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment