Jan Burse wrote:
> Lew schrieb:
>> You make it sound so dire. Allocating these objects takes next to no
>> time, GC will be fast since they'll all be unreachable, and you don't
>> have to worry about it. Not only that, but Hotspot will probably
>> optimize away the object calls in favor of primitives anyway, possibly
>> enregistered.
>
> The hotspot is not infinitely smart, and alloc/gc is not negliable.
> Try the following two codes:
>
> Variant 1:
>
> Color red=new Color(0xff0000);
> g.setColor(red);
> for (int x=0; x<1000; x++) {
> for (int y=0; y<1000; y++) {
> g.drawRect(x,y,1,1);
> }
> }
>
> Variant 2:
>
> for (int x=0; x<1000; x++) {
> for (int y=0; y<1000; y++) {
> Color red=new Color(0xff0000);
> g.setColor(red);
> g.drawRect(x,y,1,1);
> }
> }
>
> There is a huge difference between the two
> in performance.
Huge relative to what? The JDBC calls through to the database?
I don't think so.
Furthermore, you give no evidence that the example you show is bound by
allocation or GC performance, rather than the speed of graphics calls.
What
does g.setColor() do?
By pulling the setColor() call inside the loop, you make it unclear
whether
it's that or the 'new' call that is causing your overhead.
You don't show how much difference allocation makes, nor GC, nor how it
fits
into the context of *database* calls, which are not CPU bound.
Again I say, you are performing premature optimization, absent any
evidence
that the allocation and GC are causing you any significant time overhead
relative to your application. I suggest that you *measure* the impact of
the
allocations and GCs, which will be very fast.
Are you really setting the color a million times in a row, vs. setting it
once
for a million operations? Do you have a million calls into the database
in a
short time, thus motivating your optimization concerns?
Somehow I don't think so.
--
Lew
|
