Thanks for your help. I do not see a reference to statementCaching in my version of the docs.
See: http://svn.apache.org/repos/asf/ibatis/trunk/java/ibatis-2/ibatis-2-docs/en/ iBATIS-SqlMaps-2_en.pdf Is there more recent docs available other than the ones I have? -----Original Message----- From: Chema [mailto:demablo...@gmail.com] Sent: Saturday, January 31, 2009 1:54 PM To: user-java@ibatis.apache.org Subject: Re: SQL-Map / CDATA Performance Issue About docs: statementCachingEnabled (iBATIS versions 2.3.0 and later) With this setting enabled, iBATIS will maintain a local cache of prepared statements. This can lead to significant performance improvements. Example: statementCachingEnabled="true" Default: true (enabled) I asked you this question because: - I can understand that formatted XML could be parsed slower, but in millis terms - I guess that iBatis builds your query as a prepared statement and, if prepared statements cache is working fine, your query should be cached, so - I think that althought you execute it 10.000 times, XML is parsed just one time. But this conclusion is only based on how I think prepared statements caching works. But I can be wrong :-) 2009/1/31 M. Goodell <mggl...@comcast.net>: > > Version: ibatis-2.3.4.726 > > Not using statement caching as far as I know. > > Could you please provide a brief example of turning on statement caching? I > have read without it there is a performance hit. > > Thanks! > > M. Goodell > > -----Original Message----- > From: Chema [mailto:demablo...@gmail.com] > Sent: Saturday, January 31, 2009 1:12 PM > To: user-java@ibatis.apache.org > Subject: Re: SQL-Map / CDATA Performance Issue > > > What version are you using ? > Do you have statement caching enabled ? > > > 2009/1/31 M. Goodell <mggl...@comcast.net>: >> Looking further into this it seems to have little to do with the CDATA tag >> but the formatting of the SQL statement. The more formatting applied to > the >> SQL statement, the slower the performance. >> >> Format A is much slower than Format A >> >> (Format A) >> INSERT INTO >> people ( >> last_name, >> first_name, >> age >> ) VALUES ( >> #lastName#, >> #firstName#, >> #age#); >> >> (Format B) >> INSERT INTO people (last_name,first_name,age) VALUES >> (#lastName#,#firstName#,#age#); >> >> -----Original Message----- >> From: M. Goodell [mailto:mggl...@comcast.net] >> Sent: Saturday, January 31, 2009 12:52 PM >> To: Chema; user-java@ibatis.apache.org; mggl...@comcast.net >> Subject: RE: SQL-Map / CDATA Performance Issue >> >> >> Here is some more information: >> >> 1.) Using (Format A) and inserting 10,000 records this takes roughly 12-15 >> seconds. >> >> (Format A) >> <![CDATA[ >> INSERT INTO people ( >> last_name, >> first_name, >> age >> ) VALUES ( >> #lastName#, >> #firstName#, >> #age# >> ); >> ]]> >> >> 2.) Using (Format B) and inserting 10,000 records this takes roughly 7-8 >> seconds. >> >> (Format B) >> INSERT INTO people ( >> last_name, >> first_name, >> age >> ) VALUES ( >> #lastName#, >> #firstName#, >> #age# >> ); >> >> 3.) Using (Format C) and inserting 10,000 records this takes roughly 3-4 >> seconds. >> >> (Format C) >> INSERT INTO people (last_name, first_name, age) VALUES >> (#lastName#,#firstName#,#age#); >> >> Again, thanks for any help. >> >> -----Original Message----- >> From: Chema [mailto:demablo...@gmail.com] >> Sent: Saturday, January 31, 2009 12:24 PM >> To: user-java@ibatis.apache.org; mggl...@comcast.net >> Subject: Re: SQL-Map / CDATA Performance Issue >> >> >> And without CDATA tag ? Same performance ? >> Indeed, I don't know why you use it for that query >> >> >> 2009/1/31 MGG List Subscription <mggl...@comcast.net>: >>> When I format the SQL within my insert element like Example 1.0 and time >>> several application calls the performance is degraded *substantially*. >>> However, if I format the SQL as shown in Example 1.1 the performance >>> improves dramatically. >>> >>> It seems the larger the SQL statement and the more "pretty" formatting >> that >>> is applied to the embedded SQL statement causes the performance to >> degrade. >>> I have read the manual sections on applying the CDATA XML tag to the SQL >> but >>> it seems to not make a difference unlsess the SQL is compacted on to one >>> line. >>> >>> Thank you in advance for any help! >>> >>> Example 1.0: >>> >>> <insert id="insertPerson" parameterClass="springibatis.Person"> >>> <![CDATA[ >>> INSERT INTO people ( >>> last_name, >>> first_name, >>> age >>> ) VALUES ( >>> #lastName#, >>> #firstName#, >>> #age# >>> ); >>> ]]> >>> </insert> >>> >>> >>> Example 1.1: >>> >>> <insert id="insertPerson" parameterClass="springibatis.Person"> >>> <![CDATA[ >>> INSERT INTO people (last_name, first_name, age) VALUES > (#lastName#, >>> #firstName#, #age#); >>> ]]> >>> </insert> >>> No virus found in this outgoing message. >>> Checked by AVG - www.avg.com >>> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: > 01/30/09 >>> 17:31:00 >>> >>> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 >> 17:31:00 >> >> No virus found in this outgoing message. >> Checked by AVG - www.avg.com >> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 >> 17:31:00 >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 >> 17:31:00 >> >> No virus found in this outgoing message. >> Checked by AVG - www.avg.com >> Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 >> 17:31:00 >> >> > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 > 17:31:00 > > No virus found in this outgoing message. > Checked by AVG - www.avg.com > Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 > 17:31:00 > > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 17:31:00 No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.0.233 / Virus Database: 270.10.16/1926 - Release Date: 01/30/09 17:31:00
