Well, after some more profiling, i've found that creating a
BufferedImage is really really slow.
This line takes 0.3 seconds to execute (w=810,h=407) on my machine:
BufferedImage curImage = new BufferedImage(width, height,
BufferedImage.TYPE_4BYTE_ABGR);
This (different datatype) takes just a wee bit less time:
BufferedImage curImage = new BufferedImage(width, height,
BufferedImage.TYPE_INT_ARGB);
Tracking through the code, you eventually get to this line:
// size is 1,318,680
byte data = new byte[size];
This takes about 0.26 seconds to execute!!
This is a *HUGE* cost for creating an image! To put this in
perspective, drawing the image take about 0.8sec, and converting it to
PNG takes about 0.15sec.
This also means that trying to "parallelize" the lite renderer is
unlikely to actually speed it up!
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
dblasby@anonymised.com wrote:
Tracking through the code, you eventually get to this line:
// size is 1,318,680
byte data = new byte[size];
This takes about 0.26 seconds to execute!!
David, how did you get that numbers? Sometimes profileres lies (I've been
bitten in the past by a profiler that over-estimated memory allocation costs).
Hmm... anyway, a little experiment may shed some light on this: you could create
a load test that requires over and over the same map, and have the map server allocate the buffered image just once (and cache it).
If there are noticeable speed improvements, we could think about creating a
buffered image pool.
About the volatile images, Jesse is right, it could be massively faster, but...
we need some more context. Volatile images are created transparently when you
request a BufferedImage by java 1.5 under Windows. I don't know if a volatile
image is created automatically under Linux, and I believe it won't if you're
running on a headless setup.
If you're running on 1.4, you must write explicit code in order to use volatile
images. Chet Haase has written a few blogs on that:
http://weblogs.java.net/blog/chet/archive/2004/08/toolkitbuffered.html
http://weblogs.java.net/blog/chet/archive/2003/09/volatileimage_n.html
http://weblogs.java.net/blog/chet/archive/2003/09/volatileimage_q.html
http://weblogs.java.net/blog/chet/archive/2003/08/bufferedimage_a_1.html
Hum... maybe we could introduce an ImageProvider interface and use an appropriate implementation depending on the platform we're running on (Windows/Linux headless/non headless jdk 1.4/jdk 1.5).
Hope this helps.
Best regards
Andrea Aime
Have you checked how long it takes to create an Image using a awt
components. For example: frame.createImage( width,height );
The default isn't ABGR but you can create one with alpha's by obtaining
the Graphics configuration and creating one using that. Also try out
the volatile images they might be even quicker to create.
Jesse
On Sun, 2005-08-07 at 14:48 -0400, dblasby@anonymised.com wrote:
Well, after some more profiling, i've found that creating a
BufferedImage is really really slow.
This line takes 0.3 seconds to execute (w=810,h=407) on my machine:
BufferedImage curImage = new BufferedImage(width, height,
BufferedImage.TYPE_4BYTE_ABGR);
This (different datatype) takes just a wee bit less time:
BufferedImage curImage = new BufferedImage(width, height,
BufferedImage.TYPE_INT_ARGB);
Tracking through the code, you eventually get to this line:
// size is 1,318,680
byte data = new byte[size];
This takes about 0.26 seconds to execute!!
This is a *HUGE* cost for creating an image! To put this in
perspective, drawing the image take about 0.8sec, and converting it to
PNG takes about 0.15sec.
This also means that trying to "parallelize" the lite renderer is
unlikely to actually speed it up!
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/