What's the best/fastest way to access image data

John B. Matthews wrote:
> In article
> <8a970851-2353-4106-af7b->,
> "G.W. Lucas" <> wrote:
>
>> Although the sample set was pretty small, I'm pretty
>> sure there are no statistically significant difference in the time
>> required to build images


I'd also like to thank you for reporting these results. It's good to
know that there weren't some other gotchas waiting for you further down
the road.

> Interesting; thank you for reporting your results. I missed the import
> of markspace's suggestion: it was predicated on the reasonable
> assumption that array access would be faster than method invocation.


Not quite. I was basing by prediction on the idea that buffer copies
should be avoided. In other words, the method call I focused on didn't
just use setters and getters, it copied the entire 3,000,000 word pixel
buffer, before handing the copy to the caller. This also means that the
3,000,000 buffer gets allocated twice. Once when the BufferedImage is
created, and once again when the OP had to allocate a second buffer.

Both of these operations are avoided in the code I posted. The buffer
is allocated once, and never copied.

Modern CPUs impose a high penalty for large numbers of consecutive reads
and writes. In typical algorithm analysis, all reads and writes are
assumed to be the same value. However, this doesn't work for long
strings of consecutive reads and writes, because they can't be cached,
and therefore don't benefit from locality of access the way that other
reads and writes do.

In other words, most memory access have a lower amortized access time,
due to locality and the CPU cache. Memory that is access precisely once
doesn't benefit from this amortized time, and has to pay the full cost
of a cache miss, main-memory access, and then the eventual main-memory
write. A long string of such accesses is particularly painful.

If that's all too much to remember, then just remember that "buffer
copies are bad" and go with that.

> My
> experience with mixing WritableRaster and Graphics2D operations is that
> the latter tend to dominate and the former are fast enough. Still, 'it's
> interesting to see how to construct a BufferedImage with one's own data
> buffer.


It would be interesting to compare the method calls in a writable raster
with direct buffer access, like the OP was doing. I suspect they are
similar and the performance hit using method calls vs. direct access
isn't as large as most folks would believe. However, the OP wanted a
raw array, so that's what I gave him.

markspace

G.W. Lucas wrote:
> On Nov 2, 8:02 pm, markspace <nos...@nowhere.com> wrote:
>> G.W. Lucas wrote:
>>> The thing I was wondering about is if the resulting
>>> BufferedImage will have the same performance as the ones which I am
>>> currently creating with the less-advanced constructor. [snip]
>> Please do report back on your findings if you can. I'm interested if
>> this technique is general and will work for other folks.
>
> Fortunately, I've always been interested in performance considerations
> (who isn't?), so I've got plenty of timing instrumentation
> already in place for my application. I was
> able to run the program a dozen or so times alternating between
> the different constructors. Although the sample set was pretty small,
> I'm pretty sure there are no statistically significant difference
> in the time required to build images (for a while there, I actually
> thought the WritableRaster constructor might have an edge, but
> that was just a result of a noisy test environment).
>
> Thanks again for all your help.
>
> g.
I hope you *also* use a profiler

Daniel Pitts

On Nov 2, 2:55 pm, "G.W. Lucas" <gwlu...@sonalysts.com> wrote:
> I have an application that performs some specialized image-processing
> which is simple, but not supported by the JAI or other Java API.

And I take it it's not supported either by 3D hardware-accelerated
APIs? Because if it's supported by such hardware, then you can
bypass the entire software stack and the gains are expressed in
orders of magnitude (even when called from Java

alexandre_paterson@yahoo.fr