Low performance of MemoryCacheUtil.generateKey(String imageUri, ImageSize targetSize)

[Alex100]

Hello,

I analyzed my app with the traceviewer and detected that the generateKey method in MemoryCacheUtil class needs a lot of execution time (2,39ms). This method is called in the main thread for each image which is displayed by the image loader. If you suppose that a frame rate of 60fps is needed for smoothly rendering, then you must render each frame in less than 16ms!
The performance lack is caused by the call of String.format() in generateKey() which isn't really fast: http://stackoverflow.com/a/1281651/1185087

Also it would be great if the thread of the LoadAndDisplayImageTask is interrupted if the task is canceled. At the moment methods like the copyStream method of the IoUtils class were finished even though the task is canceled already.

Best regards,
Alex.

[nostra13]

Hi,
Thanks for the tip about String.format(). I replaced it with StringBuilder using but actually didn't mentioned any significant improvement.

Why do you think copyStream is needed to be interrupted? I don't want to interrupt such operations as copyStream because it can cause unpredictable state of cached files (or something else).

[Alex100]

Hello again,

I didnt ' look at any part of your code but I discovered that a cancelled task takes quite a long time after it completely finished its operations (Mb that are expensive read and write memory operations?). I think that this could be the reason for my out of memory exceptions when I use the image loader on old devices combined with a view pager. I tried already all of your suggested fixes of your readme. Additionally I use an image view pool to reuse images and I recycle each bitmap before I reuse the image.But when I wipe fast I still get these exceptions. So could it be that cancelled tasks will regardless write an incoming byte stream of an now unused image as decoded bitmap in the memory? I see only the increasing number of tasks which were started when I wipe through the images...
If you read and write your input and output streams byte-wise or multiple byte-wise in while loops you can verify in the loop condition if the thread of the task is interrupted and call a clean up function.
At least a fast optimization would be a "cancel-check" before each of your disc- and memory write and read operations.

[nostra13]

#247