Return-Path: Delivered-To: apmail-ant-user-archive@www.apache.org Received: (qmail 21307 invoked from network); 25 Nov 2003 20:05:50 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 25 Nov 2003 20:05:50 -0000 Received: (qmail 45173 invoked by uid 500); 25 Nov 2003 19:43:50 -0000 Delivered-To: apmail-ant-user-archive@ant.apache.org Received: (qmail 45144 invoked by uid 500); 25 Nov 2003 19:43:49 -0000 Mailing-List: contact user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list user@ant.apache.org Received: (qmail 45128 invoked from network); 25 Nov 2003 19:43:49 -0000 Received: from unknown (HELO hotmail.com) (65.54.247.49) by daedalus.apache.org with SMTP; 25 Nov 2003 19:43:49 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Nov 2003 11:43:54 -0800 Received: from 205.246.2.35 by by2fd.bay2.hotmail.msn.com with HTTP; Tue, 25 Nov 2003 19:43:54 GMT X-Originating-IP: [205.246.2.35] X-Originating-Email: [richmwagner@hotmail.com] From: "Rich Wagner" To: user@ant.apache.org Cc: richmwagner@hotmail.com Bcc: Subject: Cutting Ant overhead (was "Could Ant build scripts be compiled?") Date: Tue, 25 Nov 2003 19:43:54 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Nov 2003 19:43:54.0611 (UTC) FILETIME=[7596B430:01C3B38C] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Well, not to discourage anyone from actually implementing a compiler, if they so desire... Maybe concentrating on the 80/20 rule-of-thumb is best first. I mean, yes, compiled Ant code would no doubt be fastest (theoretically), but... What if an Ant front-end existed which did two things... First, the front-end would be Java-based, have either a GUI or a simple stdin-based command interpreter. But most importantly, the front-end would NOT quit (a la "System.exit") after one Ant invocation and before the next Ant invocation. For instance, the front-end could call Ant's "main" directly, instead of spawning a new sub-process for each "Ant" invocation. (Calls to System.exit in Ant would need to be "caught", e.g. via a SecurityManager restriction...) What does that buy ? Well, you then incur JVM (and a LOT of class-loading) start-up costs only once, instead of once PER Ant invocation. Secondly, and going one step farther... Instead of the front-end calling Ant's "main" method, the front-end could potentially use a modified version of that "main" method's code -- specifically an implementation which uses cached XML Dom trees which correspond to formerly read and parsed Ant build files. Doing so would again replace the once-per-Ant-invocation XML parsing cost with a once-per-buildfile parsing cost. Again, these things would fall short of what a compiler could do (though the compiled code should ideally avoid the JVM-startup per Ant invocation cost, right ?). Just some thoughts... Rich Wagner > >From: Stirling, Scott [mailto:scott.stirling@workscape.com] > >Subject: Could Ant build scripts be compiled? > > > >Hi, > > > >Just a thought I've been holding onto for a while. > > > >Could we benefit from compiling Ant build scripts? They would > >load faster if the XML didn't have to be parsed. They would > >be less open to unwanted modification (if you ship build > >scripts with a product, for example). They might run faster, > >although I'm not as sure about that. > > > >What would they be compiled down to? I guess the best answer > >would be, a Java class. Ant would have to be able to load a > >class rather than a build script for this to work. > > > >Any thoughts? > > > >Scott Stirling > >Workscape, Inc. _________________________________________________________________ Say �goodbye� to busy signals and slow downloads with a high-speed Internet connection! Prices start at less than $1 a day average. https://broadband.msn.com (Prices may vary by service area.) --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org