From abaacf6c4ef9ce7e4f41e335240c8a34d870e907 Mon Sep 17 00:00:00 2001 From: dcommander Date: Thu, 10 Mar 2011 07:25:41 +0000 Subject: Add notes about performance git-svn-id: https://libjpeg-turbo.svn.sourceforge.net/svnroot/libjpeg-turbo@515 3789f03b-4d11-0410-bbf8-ca57d06f2519 --- trunk/java/README | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'trunk/java') diff --git a/trunk/java/README b/trunk/java/README index 87d3181..ebe564e 100644 --- a/trunk/java/README +++ b/trunk/java/README @@ -18,6 +18,25 @@ compress and decompress JPEG images in memory. builds .class files for both the front end and example code. +Performance Pitfalls +-------------------- + +The TurboJPEG Java front end defines several convenience methods which can +allocate image buffers or instantiate classes to hold the result of compress, +decompress, or transform operations. However, if you use these methods, then +be mindful of the amount of new data you are creating on the heap. It may be +necessary to manually invoke the garbage collector to prevent heap exhaustion +or to prevent performance degradation. Background garbage collection can kill +performance, particularly in a multi-threaded environment (Java pauses all +threads when the GC runs.) + +The Java front end always gives you the option of pre-allocating your own +source and destination buffers, which allows you to re-use these buffers for +compressing/decompressing multiple images. If the image sequence you are +compressing or decompressing consists of images of the same size, then +pre-allocating the buffers is recommended. + + Note for OS X users ------------------- -- cgit v1.2.3