Menu
▾
▴
#99 TImage32 file load performance
An application that I'm developing (the same one mentioned in my Feature Requests post "Synchronized scrolling") is required to load anything from a couple of images to several thousand at any given point in time. I've noticed that when using Graphics32 as the sole graphics engine, the application has a marked increase in performance - except when loading images. For example (on a AMD Phenom 9600 x4 with 4GB memory):
TPicture load/TBitmap scan:
3996 files load in 26:28, scan in 24:30
TImage32
3996 files load in 27:27, scan in 16:24
As you can see with the above, using only Graphics32, 3996 files took just about 1 minute longer to load, but scan times was reduced by about 8 minutes (which is exactly why I've shifted to using Graphics32). As a consequence, my application uses the standard TPicture to load it's working set of images, which are drawn to a TImage32 surface when they need to be scanned.
While 1 minute slower in the load times does not appear to be much, this is only an example, and the difference is far more pronounced when dealing with larger image sets. Not really a bug, I know, but Graphics32 is about performance, right? So perhaps a bit of tweaking of the loading methods could speed things up a little?
Can you give us any hint what graphic format you are using? BMP, JPG, PNG? In case of BMP TBitmap loading is supposed to be faster, as it loads the graphic exactly in its original format, where as GR32 always converts the graphics to its internal 32bit format. While with this format several processing steps can be performed faster (due to the alignment of the data and the use of SSE2), the memory bandwidth needed to work with the data might be larger than any other format. Thus a longer load time can be explained perfectly.
Further than that there is nearly no way to speedup loading. Eventually - if the hard disk is limiting the processing - you can try a double buffered scenario, where you first read the images from your hard disk to the memory and in a seperate thread load the images from memory. With this approach you can eventually speed up loading by optimizing the bottleneck of transfering the data from the harddisk to the memory by using block sizes identical to your hard drive block size (typically 4K). However, this might only improve the loading slightly.
My Duplicate Image Finder application works with BMP, JPG, PNG, and GIF images...