From derby-dev-return-22-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Mon Aug 16 12:22:09 2004 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 81862 invoked from network); 16 Aug 2004 12:22:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 16 Aug 2004 12:22:09 -0000 Received: (qmail 54165 invoked by uid 500); 16 Aug 2004 12:22:08 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 54111 invoked by uid 500); 16 Aug 2004 12:22:08 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "Derby Development" Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Delivered-To: moderator for derby-dev@db.apache.org Received: (qmail 70339 invoked by uid 99); 16 Aug 2004 07:06:41 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Message-ID: <41205D74.2000801@jansdal.dk> Date: Mon, 16 Aug 2004 09:08:36 +0200 From: Steen Jansdal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derby Development Subject: Re: Derby Engine Architecture Qucik Overview References: <411D21E6.5030901@debrunners.com> In-Reply-To: <411D21E6.5030901@debrunners.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Daniel John Debrunner wrote: > ~ 1 parse using a parser generated by Javacc, results in a tree of > query nodes How is Javacc compared to ANTLR? How does the output from Javacc look like? The output from ANTLR is a nice looking readable java file that you can debug/single step through. Note: I have absolutely no experience with Javacc. > ~ 4 generation of a Java class (directly to byte code) to represent > the statement plan > ~ 5 loading of the class and creation of an instance to represent that > connection's state of the query > The generated statement plan is cached and can be shared by multiple > connections. DDL statements (e.g. CREATE TABLE use a common statement > plan to avoid generation of a Java class file) Interesting concept! How is the speed compared to a "normal" plan executer? The first couple of times the statement plan are executed, it would be interpreted. Only after a number of executions the hot spot compiler will decide to compile this into native code. Is this concept also supported in J2ME? regards Steen Jansdal --------------------------------------------------------------------- Derby is a project of the Apache Incubator (http://incubator.apache.org) To unsubscribe, e-mail: derby-dev-unsubscribe@db.apache.org For additional commands, e-mail: derby-dev-help@db.apache.org