Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 33259 invoked from network); 31 Jan 2008 21:11:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 Jan 2008 21:11:59 -0000 Received: (qmail 64464 invoked by uid 500); 31 Jan 2008 21:11:47 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 64453 invoked by uid 500); 31 Jan 2008 21:11:47 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 64442 invoked by uid 99); 31 Jan 2008 21:11:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2008 13:11:47 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hh4ross@gmail.com designates 209.85.162.183 as permitted sender) Received: from [209.85.162.183] (HELO el-out-1112.google.com) (209.85.162.183) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2008 21:11:20 +0000 Received: by el-out-1112.google.com with SMTP id o28so335852ele.24 for ; Thu, 31 Jan 2008 13:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=LfaJTjFSz1DrePqX/MV4lNqzkJMoAT4NsXwdz1JA3bI=; b=t2PwFbox3i98lnHP8AqRzMokTyWUqyykbGlOLOsliTlo/8B2RhQokAB2xXOnJ8QjSbcJlgL6TOS7ql4bRumJnF05YiaFKgPUP8KHA/INbvxoGyOMN13dXfatUR8FBRBK8WlDhJk1TkD43MDHzFYZwBq1WXA/RhChndnLfKbZQzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=NaBuRMwh9v+p1avtiwgWShfzXKZdpziE9Ry2EMDwXGBZ+gUfaMfroAjO3+m36k5hlB1JTKHspBTCaX4YCXNWBu/YCWXTaNlvPALE5ipYxGtFpp8IsNlfMw3n7+uw11pwYD0owZX1fzzQ76Ae+ivLi1cHwU2SchO0iDt/8I1npwM= Received: by 10.142.148.7 with SMTP id v7mr1588356wfd.153.1201813469984; Thu, 31 Jan 2008 13:04:29 -0800 (PST) Received: by 10.142.178.18 with HTTP; Thu, 31 Jan 2008 13:04:29 -0800 (PST) Message-ID: Date: Thu, 31 Jan 2008 16:04:29 -0500 From: "Hugh Ross" To: user-java@ibatis.apache.org Subject: Re: How does RowHandler help performance? In-Reply-To: <47a22927.0d528c0a.53f3.ffffce92@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27674_24112499.1201813469984" References: <47a22927.0d528c0a.53f3.ffffce92@mx.google.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_27674_24112499.1201813469984 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks. I see now the key difference. The queryWithRowHandler methods do not return anything! I was thinking the List was built anyway. So, assuming I don't build my own List in the RowHandler, it saves memory. Got it. Definitely should be considered for larger result sets that only need to be processed once. Hugh On 1/31/08, Clinton Begin wrote: > > Row handlers are not necessarily faster... they just use less memory. > Thus, if you count the time to resize arrays, grow the heap and possibly > garbage collect, they will be faster for indirect reasons. > > > > Internally, by default, iBATIS uses a RowHandler that simply gathers up > all of the result objects and adds them to a list to be returned (it > actually uses it even for a single queryForObject as well). > > > > So if you write your own RowHandler implementation, it's possible to > process row-by-row... > > > > That's a pretty rare thing to do in most transactional and/or web based > systems. It's more for batch processing of lots of rows. > > > > One example of where I used a row handler was for an integration task > between a MySQL database and a SQL Server... ETL of sorts. The RowHandler > would read from MySQL, transform the record, perform some simple > calculations, and batch inserts into SQL Server. On my test machine running > both databases (3GHz 2GB RAM 2x10k HDD), I was able to achieve throughput of > 15,000 records per second on millions of rows. > > > > So they CAN be fast. They aren't just fast by default, and they're not > for every situation. > > > > Clinton > > > > *From:* Hugh Ross [mailto:hh4ross@gmail.com] > *Sent:* January-31-08 12:39 PM > *To:* user-java@ibatis.apache.org > *Subject:* How does RowHandler help performance? > > > > > > I've looked at the docs (In Action book, Developer Guide 2.0, and wiki), > and somehow I've missed this. > > > > I have seen threads in the user-java Mail Archive saying that it can, but > I'm not clear on how. > > > > Thanks... > > > > P.S. Actually, I believe only the Dev Guide mentions RowHandler > specifically, and there only briefly. > ------=_Part_27674_24112499.1201813469984 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
Thanks.  I see now the key difference.  The queryWithRowHandler methods do not return anything!  I was thinking the List was built anyway. 
 
So, assuming I don't build my own List in the RowHandler, it saves memory.  Got it.  Definitely should be considered for larger result sets that only need to be processed once.
 
Hugh
 
On 1/31/08, Clinton Begin <clinton.begin@gmail.com> wrote:

Row handlers are not necessarily faster... they just use less memory.  Thus, if you count the time to resize arrays, grow the heap and possibly garbage collect, they will be faster for indirect reasons. 

 

Internally, by default, iBATIS uses a RowHandler that simply gathers up all of the result objects and adds them to a list to be returned (it actually uses it even for a single queryForObject as well).

 

So if you write your own RowHandler implementation, it's possible to process row-by-row...

 

That's a pretty rare thing to do in most transactional and/or web based systems.  It's more for batch processing of lots of rows.

 

One example of where I used a row handler was for an integration task between a MySQL database and a SQL Server... ETL of sorts.  The RowHandler  would read from MySQL, transform the record, perform some simple calculations, and batch inserts into SQL Server.  On my test machine running both databases (3GHz 2GB RAM 2x10k HDD), I was able to achieve throughput of 15,000 records per second on millions of rows.

 

So they CAN be fast.  They aren't just fast by default, and they're not for every situation.

 

Clinton

 

From: Hugh Ross [mailto:hh4ross@gmail.com]
Sent: January-31-08 12:39 PM
To: user-java@ibatis.apache.org
Subject: How does RowHandler help performance?

 

 

I've looked at the docs (In Action book, Developer Guide 2.0, and wiki), and somehow I've missed this.

 

I have seen threads in the user-java Mail Archive saying that it can, but I'm not clear on how.

 

Thanks...

 

P.S.  Actually, I believe only the Dev Guide mentions RowHandler specifically, and there only briefly.


------=_Part_27674_24112499.1201813469984--