-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Of Semaphore for avoiding unnecessary downloads/loads #44
Comments
I've made some tests with double cache without any speed improvement, so for the moment ignore it. For the second idea one way would be like this: On ImageLoader: A map that given a url returns a Lock, a method for get a existing lock or new one given a url, and a method that deletes an unused lock with a given url. private Map<String, ReentrantLock> taskLocks = Collections.synchronizedMap(new WeakHashMap<String, ReentrantLock>());
private ReentrantLock getLock(String uri) {
ReentrantLock lock = taskLocks.get(uri);
if (lock == null) {
lock = new ReentrantLock();
taskLocks.put(uri, lock);
}
return lock;
}
public void removeLock(String uri) {
taskLocks.remove(uri);
} When calling LoadAndDisplayImageTask we should pass de corresponding lock: LoadAndDisplayImageTask displayImageTask = new LoadAndDisplayImageTask(configuration, imageLoadingInfo, new Handler(), display, getLock(imageLoadingInfo.uri)); The run method of LoadAndDisplayImageTask would have this structure: @Override
public void run() {
if(lock!=null){
lock.lock();
}
try {
//CODE (verifying if the image is in memory cache)
} finally {
if(lock!=null){
lock.unlock();
if(!lock.hasQueuedThreads()){
ImageLoader.getInstance().removeLock(imageLoadingInfo.uri);
}
}
}
} Also another point to consider is aborting immediately any operation over images that are not on screen. That happens very often when scrolling. At every stream read/write should be verified that the image is on screen, and if not the case abort it. |
Thanks, yevon, for your work. Appreciate it. |
With a sempahore / lock you get this behaviour. The idea I gave you doesn't already do that?. 1 -Get a lock for a corresponding Url. -> return for example googleLock Pseudo Code Lock lock = getLock(String url);
lock.lock();
Bitmap b = getFromMemoryCache();
if(b == null){
b = getFromDisckCache();
if(b == null){
b = getBitmapFromYouWant
Scale, compress bitmap;
putToMemoryCache(b);
putToDiskCache(b);
}
}
lock.unlock();
postToUiThread(b, ImageView) Every url has its lock, so you are only blocking all threads that are requesting that url, not other urls. The first one will put it into memory cache, then all others will wake up at the same time getting it from memory cache. |
Maybe I didn't explain clearly what I meant. |
Ahh yess now I understand you. I don't think that it is noticeable, because getting the image from memory should be practically instant. mm a solution could be using a sempahore initialized with the size of the thread pool (10 for example). Mmm i think that this can be done with something like... semaphore.waitingThreads.size() == 0. if(semaphore.waitingThreads.size() == 0){ same for release |
Will try it. Thanks. |
Right, difference isn't noticeable. |
I'm looking into new ways to improve speed significantly. Apart from creating a sized cache version of the image, that i know you're working on, i have new ideas.
I haven't made any test of that one:
Think on a listView full of Images. If they were cached alternatively, one on external disk cache and the other on internal disk cache, the read speed would be greatly improved.
Also there is an issue when you have a list with allways the same url repeated. Imagine that there are 10 image thumbnails on screen.The first time it is downloaded from internet/disk up to 5 times! that is due to there is any request control over the same url. The requests over the same url should be blocked until the image is downloaded to memory/disk cache. This can be achieved using semaphores. I will post some sample code later from the last issue!.
The text was updated successfully, but these errors were encountered: