Submission: IMG_Init and IMG_Quit for faster loading

I was looking through the event log of one of my programs that does a lot of image loading, and saw several hundred repeats of the notification that libpng.dll and zlib.dll had been loaded and then unloaded. A bit of checking around in IMG_png.c confirmed my suspicions: It was loading and unloading libpng (which had its own dependency on zlib) for every single image. There was code built into IMG_InitPng() to prevent this, but it never actually gets used. So I wrote up a quick patch to enable it, adding IMG_Init() and IMG_Quit() routines that work a lot like SDL_Init() and SDL_Quit().

The results were dramatic. Not unloading and reloading the DLLs every time shaved about 43 seconds off of a loop that processed 357 PNG images! (On a nice, fast quad-core system with 4 GB of RAM!) Apparently there’s some pretty significant overhead associated with those loads and unloads. This will really boost performance for anyone who needs to load up a bunch of images.

I give my permission for this code to be used in the SDL_Image library, under whatever licenses Sam chooses to release it under.

(This patch assumes that the one I submitted yesterday has already been applied, but isn’t dependent on it.)
-------------- next part --------------
A non-text attachment was scrubbed…
Name: img_init.diff
Type: application/octet-stream
Size: 1805 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090406/7d8320b6/attachment.obj

Holy CRAP. That might help an app like Tux Paint a LOT.
(Since we load countless PNGs individually, via IMG_Load())

This affects all platforms, or just Windows?

-bill!On Mon, Apr 06, 2009 at 11:59:26AM -0700, Mason Wheeler wrote:

I was looking through the event log of one of my programs that does a lot of image loading, and saw several hundred repeats of the notification that libpng.dll and zlib.dll had been loaded and then unloaded. A bit of checking around in IMG_png.c confirmed my suspicions: It was loading and unloading libpng (which had its own dependency on zlib) for every single image.

Holy CRAP. That might help an app like Tux Paint a LOT.
(Since we load countless PNGs individually, via IMG_Load())

This affects all platforms, or just Windows?

C isn’t my strong suit, but it sure looks to me like IMG_InitPNG() works
the same way for every platform that supports dynamic loading…>----- Original Message ----

From: Bill Kendrick
Subject: Re: [SDL] Submission: IMG_Init and IMG_Quit for faster loading

This sounds like a pretty decent performance gain. Did you test by loading
large, small, or a combination of images of varying size? I.E. loading 16x16
icons verses something larger like wallpapers…
The way you are explaining it, I think that the 43 second gain(approx 1/10th
of a second per image) should apply regardless of image size.


This sounds like a pretty decent performance gain. Did you test by loading large, small,
or a combination of images of varying size? I.E. loading 16x16 icons verses something
larger like wallpapers…
The way you are explaining it, I think that the 43 second gain(approx 1/10th of a second
per image) should apply regardless of image size.

Yeah. The affected code was running once per image. Also, it’s worth noting that
current SDL_Image users probably won’t get quite as big of a boost as I did, since I’m
using the PNG-saving patch, which adds a bunch of extra functions to the dynamic import
routine. Even so, the difference ought to be pretty noticeable.>From: Jonathan Greig

Subject: Re: [SDL] Submission: IMG_Init and IMG_Quit for faster loading

I was looking through the event log of one of my programs that does a lot of image loading, and saw several hundred repeats of the notification that libpng.dll and zlib.dll had been loaded and then unloaded. ?A bit of checking around in IMG_png.c confirmed my suspicions: It was loading and unloading libpng (which had its own dependency on zlib) for every single image. ?There was code built into IMG_InitPng() to prevent this, but it never actually gets used. ?So I wrote up a quick patch to enable it, adding IMG_Init() and IMG_Quit() routines that work a lot like SDL_Init() and SDL_Quit().

Wow, great catch! Thanks for your contribution!

The results were dramatic. ?Not unloading and reloading the DLLs every time shaved about 43 seconds off of a loop that processed 357 PNG images! ?(On a nice, fast quad-core system with 4 GB of RAM!) Apparently there’s some pretty significant overhead associated with those loads and unloads. ?This will really boost performance for anyone who needs to load up a bunch of images.

This is a really bad frame of reference! How long does it take without
your patch?On Mon, Apr 6, 2009 at 2:59 PM, Mason Wheeler wrote:


http://codebad.com/

The results were dramatic. Not unloading and reloading the DLLs every time
shaved about 43 seconds off of a loop that processed 357 PNG images! (On a
nice, fast quad-core system with 4 GB of RAM!) Apparently there’s some pretty
significant overhead associated with those loads and unloads. This will really
boost performance for anyone who needs to load up a bunch of images.

This is a really bad frame of reference! How long does it take without
your patch?

Actually it’s a pretty ideal frame of reference, since it tells you the relevant data
and doesn’t distract you with other numbers. For the record, the whole process
took about 85 seconds for this particular set of data, but it was doing a whole
lot more than just opening images, and separating out that functionality would
require me to re-architect the entire thing.

I believe Jonathan calculated that this amounts to a net savings of around 0.1
seconds per image, on my particular hardware and system configuration.
YMMV.>----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Submission: IMG_Init and IMG_Quit for faster loading

The results were dramatic. ?Not unloading and reloading the DLLs every time
shaved about 43 seconds off of a loop that processed 357 PNG images! ?(On a
nice, fast quad-core system with 4 GB of RAM!) Apparently there’s some pretty
significant overhead associated with those loads and unloads. ?This will really
boost performance for anyone who needs to load up a bunch of images.

This is a really bad frame of reference! How long does it take without
your patch?

Actually it’s a pretty ideal frame of reference, since it tells you the relevant data
and doesn’t distract you with other numbers.

o_OOn Mon, Apr 6, 2009 at 10:32 PM, Mason Wheeler wrote:

From: Donny Viszneki <@Donny_Viszneki>
Subject: Re: [SDL] Submission: IMG_Init and IMG_Quit for faster loading


http://codebad.com/

very cool!!!

Have you added it to the bug tracker? ( I couldn’t find it there).

http://bugzilla.libsdl.org/On Tue, Apr 7, 2009 at 4:59 AM, Mason Wheeler wrote:

I was looking through the event log of one of my programs that does a lot
of image loading, and saw several hundred repeats of the notification that
libpng.dll and zlib.dll had been loaded and then unloaded. A bit of
checking around in IMG_png.c confirmed my suspicions: It was loading and
unloading libpng (which had its own dependency on zlib) for every single
image. There was code built into IMG_InitPng() to prevent this, but it
never actually gets used. So I wrote up a quick patch to enable it, adding
IMG_Init() and IMG_Quit() routines that work a lot like SDL_Init() and
SDL_Quit().

The results were dramatic. Not unloading and reloading the DLLs every time
shaved about 43 seconds off of a loop that processed 357 PNG images! (On a
nice, fast quad-core system with 4 GB of RAM!) Apparently there’s some
pretty significant overhead associated with those loads and unloads. This
will really boost performance for anyone who needs to load up a bunch of
images.

I give my permission for this code to be used in the SDL_Image library,
under whatever licenses Sam chooses to release it under.

(This patch assumes that the one I submitted yesterday has already been
applied, but isn’t dependent on it.)


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Donny,
That should mean 128 seconds for the full load unpatched assuming he
calculated the time properly. Admittedly he is performing other calculations
too, shouldn’t factor into the overall gain anyway as multiple runs should
produce similar benchmarks.

Mason,
I think that Donny is looking for a raw benchmarking example, such as a
simple main() that initializes SDL and the libs and runs a massive loading
loop, and outputs the program time when done. That would allow others to
test the performance gain on other boxes rather than just relying on the
numbers you reported. Is there a (unit)test for that? I haven’t messed
around with those for quite some time. If not, that would be a good addition
too. It would really reinforce the validity of your claims and serve as a
test for future patches to determine their effect on performance.


Mason,
I think that Donny is looking for a raw benchmarking example, such as a
simple main() that initializes SDL and the libs and runs a massive loading
loop, and outputs the program time when done. That would allow others
to test the performance gain on other boxes rather than just relying on the
numbers you reported. Is there a (unit)test for that? I haven’t messed
around with those for quite some time. If not, that would be a good
addition too. It would really reinforce the validity of your claims and serve
as a test for future patches to determine their effect on performance.

Yeah. I don’t have anything like that, and I’m not particularly inclined to
write one up, especially in C. And especially because it would be
hard to make it cross-platform. The only way I know of to “do X to all
files in folder Y” involves the Windows API. It’s a pretty simple set
of commands, but it can’t be done the same way on Linux or OSX.

Try asking Bill Kendrick if this helps out Tux Paint very much…>From: Jonathan Greig

Subject: Re: [SDL] Submission: IMG_Init and IMG_Quit for faster loading

Yeah. I don’t have anything like that, and I’m not particularly inclined to
write one up, especially in C. And especially because it would be
hard to make it cross-platform. The only way I know of to “do X to all
files in folder Y” involves the Windows API. It’s a pretty simple set
of commands, but it can’t be done the same way on Linux or OSX.

Something like:

int i;
SDL_Surface * img[1000];
Uint32 start_time;

start_time = SDL_GetTicks();
for (i = 0; i < 1000; i++)
img[i] = IMG_Load(“the_same_image.png”);
printf(“That took %d ticks\n”, SDL_GetTicks() - start_time);

for (i = 0; i < 1000; i++)
SDL_FreeSurface(img[i]);

This would test the raw improvement to IMG_Load, without needing
to traverse folders. (Also has the benefit of being a simpler,
more boiled-down example.)

Try asking Bill Kendrick if this helps out Tux Paint very much…

I’m not running off SDL from source, but from Ubuntu packages, at the
moment. :)On Tue, Apr 07, 2009 at 06:25:51AM -0700, Mason Wheeler wrote:


-bill!
Sent from my computer

YOU can try it.

Heck, you can use the latest Tux Paint, and just swap your SDL_image.dll
around.On Tue, Apr 07, 2009 at 06:25:51AM -0700, Mason Wheeler wrote:

Try asking Bill Kendrick if this helps out Tux Paint very much…


-bill!
Sent from my computer

performance bump :stuck_out_tongue:
any news on this. Sam? Anyone?On Tue, Apr 7, 2009 at 12:41 PM, Bill Kendrick wrote:

On Tue, Apr 07, 2009 at 06:25:51AM -0700, Mason Wheeler wrote:

Try asking Bill Kendrick if this helps out Tux Paint very much…

YOU can try it.

Heck, you can use the latest Tux Paint, and just swap your SDL_image.dll
around.


-bill!
Sent from my computer


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org