Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 97633 invoked from network); 22 Dec 2004 22:40:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 22 Dec 2004 22:40:49 -0000 Received: (qmail 115 invoked by uid 500); 22 Dec 2004 22:40:48 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 99981 invoked by uid 500); 22 Dec 2004 22:40:48 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 99970 invoked by uid 99); 22 Dec 2004 22:40:48 -0000 X-ASF-Spam-Status: No, hits=2.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FROM_ENDS_IN_NUMS,HTML_40_50,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from smtp810.mail.sc5.yahoo.com (HELO smtp810.mail.sc5.yahoo.com) (66.163.170.80) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 22 Dec 2004 14:40:45 -0800 Received: from unknown (HELO rpws002) (rp0428@pacbell.net@68.125.10.130 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 22 Dec 2004 22:40:42 -0000 Message-ID: <000801c4e877$e11d1bb0$1401a8c0@rpws002> From: "RPost" To: "Derby Development" Subject: Two poorly optimized functions in SQLParser.java Date: Wed, 22 Dec 2004 14:45:04 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C4E834.D2B49550" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C4E834.D2B49550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone have any experience or knowledge about the JavaCC process = used to produce SQLParser.java? There are two functions, jj_3R_315() and jj_3R_338(), in SQLParser.java = that are very poorly optimized. jj_3R_315 contains around 115 nested IF statements and jj_3R_338 = contains over 200 nested IF statements. The statement: PreparedStatement pstmt =3D = con.prepareStatement("insert into table1 values (?)"); winds up calling jj_3R_315 three times. For each call the current token = position is at the "(" and the function executes the entire chain of 115 = calls: if (jj_scan_token(208)) { jj_scanpos =3D xsp; if (jj_scan_token(209)) { jj_scanpos =3D xsp; ... over 100 more nested if statements before finishing. A stack trace shows that the actual call to jj_3R_315 is about 15 layers = deep: jj_3_9 jj_3R_51 jj_3R_91 jj_3R_167, which calls 204, 261, 289, 310, 322, 333, 337, 343, = jj_3R_315 Most of the calling functions do no more than call one function and = returns its boolean result. I have not been able to create code that calls the jj_3R_338 function = but it is similar in structure with a depth of over 200 nested 'if' = statements. Each 'if' calls the jj_scan_token() function. The sysinfo for this is: D:\cloudscape_derby\test>d:\jdk1.3.1\bin\java -classpath = .;..\lib\derby.jar;..\lib\derbynet.jar;..\lib\derbytools.jar = org.apache.derby.tools.sysinfo=20 ------------------ Java Information ------------------ Java Version: 1.3.1 Java Vendor: Sun Microsystems Inc. Java home: d:\jdk1.3.1\jre Java classpath: = .;..\lib\derby.jar;..\lib\derbynet.jar;..\lib\derbytools.jar OS name: Windows 2000 OS architecture: x86 OS version: 5.0 Java user name: Administrator Java user home: C:\Documents and Settings\Administrator Java user dir: D:\cloudscape_derby\test --------- Derby Information -------- [D:\cloudscape_derby\lib\derby.jar] 10.0.2.1 - (56458) [D:\cloudscape_derby\lib\derbynet.jar] 10.0.2.1 - (56458) [D:\cloudscape_derby\lib\derbytools.jar] 10.0.2.1 - (56458) ------------------------------------------------------ ----------------- Locale Information ----------------- ------------------------------------------------------ Each of the three executions appear to take less than 1ms so I don't = know how long it is really taking to execute the functions but these = functions should probably be produced with 'switch' statements like many = of the other functions in this file are. Preparation time for the 'insert' statement averages about 250ms. = Inserting 100 records with: for (int i =3D 0; i < 100; i++) { pstmt.setInt(1, i); lStart =3D System.currentTimeMillis(); pstmt.execute(); lEnd =3D System.currentTimeMillis(); System.out.println(i + " " + (lEnd - lStart)); } averages about 16ms for each of the 1st 30 records and then about 266ms = for each of the remaining 70 records. ------=_NextPart_000_0005_01C4E834.D2B49550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does anyone have any experience or = knowledge about=20 the JavaCC process used to produce SQLParser.java?
 
There are = two functions, jj_3R_315() and=20 jj_3R_338(), in SQLParser.java that are very poorly = optimized.
 
jj_3R_315 contains around 115 nested IF = statements=20 and jj_3R_338 contains over 200 nested IF statements.
 
The statement:    = PreparedStatement pstmt=20 =3D con.prepareStatement("insert into table1 values = (?)");
winds up calling jj_3R_315 three times. = For each=20 call the current token position is at the "(" and the function executes = the=20 entire chain of 115 calls:
 
    if = (jj_scan_token(208))=20 {
    jj_scanpos =3D xsp;
    if=20 (jj_scan_token(209)) {
    jj_scanpos =3D = xsp;
    ... over 100 more = nested if=20 statements before finishing.
 
A stack trace shows that the actual = call=20 to jj_3R_315 is about 15 layers deep:
 
jj_3_9
  jj_3R_51
    = jj_3R_91
      = jj_3R_167, which=20 calls 204, 261, 289, 310, 322, 333, 337, 343, jj_3R_315
 
Most of the calling functions do no = more than call=20 one function and returns its boolean result.
 
I have not been able to create code = that calls the=20 jj_3R_338 function but it is similar in structure with a depth of over = 200=20 nested 'if' statements. Each 'if' calls the jj_scan_token()=20 function.
 
The sysinfo for this is:
 

D:\cloudscape_derby\test>d:\jdk1.3.1\bin\java -classpath=20 .;..\lib\derby.jar;..\lib\derbynet.jar;..\lib\derbytools.jar=20 org.apache.derby.tools.sysinfo
------------------ Java Information=20 ------------------
Java Version:    1.3.1
Java=20 Vendor:     Sun Microsystems Inc.
Java=20 home:       d:\jdk1.3.1\jre
Java=20 classpath: =20 .;..\lib\derby.jar;..\lib\derbynet.jar;..\lib\derbytools.jar
OS=20 name:         Windows 2000
OS = architecture: x86
OS version:      = 5.0
Java user=20 name:  Administrator
Java user home:  C:\Documents and=20 Settings\Administrator
Java user dir:  =20 D:\cloudscape_derby\test
--------- Derby Information=20 --------
[D:\cloudscape_derby\lib\derby.jar] 10.0.2.1 -=20 (56458)
[D:\cloudscape_derby\lib\derbynet.jar] 10.0.2.1 -=20 (56458)
[D:\cloudscape_derby\lib\derbytools.jar] 10.0.2.1 -=20 (56458)
------------------------------------------------------
----= -------------=20 Locale Information=20 -----------------
----------------------------------------------------= --
Each of the three = executions appear to=20 take less than 1ms so I don't know how long it is really taking to = execute the=20 functions but these functions should probably be produced with = 'switch'=20 statements like many of the other functions in this file = are.
 
Preparation time for the 'insert' = statement=20 averages about 250ms. Inserting 100 records with:
 
    for (int i =3D 0; i = < 100;=20 i++)
    {
      = pstmt.setInt(1,=20 i);
      lStart =3D=20 System.currentTimeMillis();
     =20 pstmt.execute();
      lEnd   =3D=20 System.currentTimeMillis();
     =20 System.out.println(i + " " + (lEnd - lStart));
   =20 }
averages about 16ms for each of the 1st = 30 records=20 and then about 266ms for each of the remaining 70 records.
 
 
------=_NextPart_000_0005_01C4E834.D2B49550--