Click here to Skip to main content
15,741,047 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
Hey all,

I need some advice for speed and efficiency. I have a program that loads a bunch of images into an array and displays them in grid form on the screen. I load the full size images (can be hundreds) into the array instead of loading each image.fromfile and display them 16 at a time. The fromfile approach is too slow to load the 16 images on demand to keep up per page (as they are 400x300). The alternative is to load in and store these images resized to the size I need (140x100) once as I am saving them, and then load the smaller thumbnails into the array. The smaller images would take less memory to have stored but I don't know if it would be any faster or more efficient. Also, I do need the full size image so I would have to load it eventually. The reason I ask is because it is taking almost a gig of memory to load the 400 images. That's a lot.

Am I explaining myself correctly?

Thanks for any advice... :)


I looks like a bit of is artificial problem. You never look at 400 images at a time. However the problem of optimization of latency due to loading time is interesting.

You need to load only as many images as you can see at one screen. It should not much more that just one high-resolution image with number of pixels several times more than the screen has, with re-sampling. I'm talking about this example just for speed comparison — it takes quite acceptable amount of time, so rendering the whole screen covered by images would take acceptable amount of time.

This latency can be improved be putting in some image cache some 100-200% of images (compared to screen-size) in memory in case the access of all images is consecutive, and most typical order of presentation is scrolling by one row. Consider some typical example: a typical screen shows 8x4 images, 4 rows of 8 images. The whole show may be many gigabytes, but you look only at some 32 images at a time. You can keep in memory some 32 * 3 image: 4 rows above the screen, 4 rows shown on screen and 4 rows below. If you scroll all your show just by one row or by 4 rows, you first render only the images already loaded in memory. When scrolled in view images are already presented, you can remove 1-4 rows from memory and load 1-4 rows to keep 4 + 4 + 4 rows in memory. In this way, the image loading happens behind the scene, when the user does not have to wait for it.

In this way, if the user tend to scroll the presentation mostly be 1-4 rows (where 4 rows is the full screen) in any direction, almost 100% of cache hits is experienced. Cache miss happens more rarely; and the latency is still acceptable if the images coming in view are loaded first, by the reasons

This strategy is typical for all uses of cache, such as CPU cache. The principles are pretty much the same and are well explained here:[^].

Share this answer
JBenhart 13-May-11 0:20am    
Thank you, that is what I was thinking. Load the previous, the current, and the next screens (the 32 images). If the user scrolls to an uncached screen, say five screens down, it will have to load those from file. Still shouldn't take up too much. One question, what if a user scrolls multiple screens at a time? After the user is past the cache, each page will take a bit to load. Any idea on how to prevent that?

Thanks again!
JBenhart 13-May-11 0:22am    
Oooh, I just realized the images are in a database, not on disk. That may change things with efficiency if it has to load them from the database (seek and retrieve time) instead of from disk.
Sergey Alexandrovich Kryukov 13-May-11 7:03am    
OK, in this case the idea of such cache gets extra justification. Think about it.
If you agree that this schema is useful, please formally accept this answer (green button).
Hi Josh,
Shall we think about a very different approach, let us keep two set of images of 'small' and 'large' type.

As you suggested try by loading thumbnail for the very first time in a lazy binding model as save back these thumbnail as 'small' images, try to re-sue these image.
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900