From 7c99822efb155546bb91ea90a94477d4fe77fd1c Mon Sep 17 00:00:00 2001 From: DRC Date: Thu, 10 Mar 2011 07:25:41 +0000 Subject: [PATCH] Add notes about performance git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@515 632fc199-4ca6-4c93-a231-07263d6284db --- java/README | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/java/README b/java/README index 87d3181..ebe564e 100644 --- a/java/README +++ b/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 ------------------- -- 2.40.0