…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.

…terval:

… it anyway