Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news-out.news.tds.net!newsreading01.news.tds.net!86597e80!not-for-mail
From: "Lew" <lew@THRWHITE.remove-dii-this>
Subject: Re: jTDS, trashes heap wi
Message-ID: <NoCdnfDnJNy1ubfVnZ2dnUVZ_r6rnZ2d@comcast.com>
X-Comment-To: comp.lang.java.databases
Newsgroups: comp.lang.java.databases
In-Reply-To: <4829DD03.6010102@fastmail.fm>
References: <4829DD03.6010102@fastmail.fm>
Content-Type: text/plain; charset=IBM437
Content-Transfer-Encoding: 8bit
X-Gateway: time.synchro.net [Synchronet 3.15a-Win32 NewsLink 1.92]
Lines: 67
Date: Wed, 27 Apr 2011 15:21:45 GMT
NNTP-Posting-Host: 96.60.20.240
X-Complaints-To: news@tds.net
X-Trace: newsreading01.news.tds.net 1303917705 96.60.20.240 (Wed, 27 Apr 2011 10:21:45 CDT)
NNTP-Posting-Date: Wed, 27 Apr 2011 10:21:45 CDT
Organization: TDS.net
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.databases:101

  To: comp.lang.java.databases
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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24