Same as groovyserv, not sure if it's using nailgun under the hood. On Wed, Aug 18, 2010 at 13:02, Philip Crotwell <[email protected]> wrote: > > A little late, but this approach sounds very similar to nailgun. I am not > sure if there is anything worth leveraging from that, but it might be useful > to at least explore how nailgun works. > > http://martiansoftware.com/nailgun/index.html > > Philip > > On Thu, Jul 29, 2010 at 4:52 AM, Pfau, Matthias <[email protected]> wrote: >> >> Hi Adam, >> thanks for your great work, this sounds like an outstanding feature. :-) >> >> You might close Ticket the follwing ticket: >> http://jira.codehaus.org/browse/GRADLE-579 >> >> It is not needed anymore as your implementation seems to be far more >> advanced. >> >> Kind Regards, >> Matthias >> ________________________________________ >> Von: Adam Murdoch [[email protected]] >> Gesendet: Montag, 26. Juli 2010 07:51 >> An: [email protected] >> Betreff: [gradle-dev] Improving startup time >> >> Hi, >> >> I've been doing some quick experiments with an approach to improve the >> startup time of Gradle. The approach involves having the 'gradle' >> command fork a build daemon process, which then does the actual build. >> The daemon process is reused by subsequent invocations of 'gradle'. This >> way, we avoid the startup time of Groovy, Gradle (and Scala, too, if >> you're using it), loading the script classes and so on. Plus we get the >> hotspot compiler kicking in. >> >> It seems like this approach might have some potential. Here are some >> numbers comparing the time to run gradle -t for Gradle's build: >> * gradle daemon 1.22s >> * gradle trunk 4.8s >> >> I thought I'd also see how we compare with Gradle 0.8, Ant 1.8.0, Maven >> 3.0-beta1, maven 2.2.1 and maven shell 0.10: >> >> 1. Using our single project benchmark build: >> - 1000 source and test classes >> - Test reports disabled, no parallel test execution >> >> to do a clean build (or clean package), from fastest to slowest: >> * gradle daemon 4.12s >> * mvnsh 6.18s >> * ant 6.96s >> * mvn2 8.08s >> * mvn3 8.87s >> * gradle0.8 9.93s >> * gradle trunk 10.54s >> >> to do a build (or package) when everything has already been built, from >> fastest to slowest: >> * gradle daemon 0.82s >> * mvnsh 2.52s >> * gradle trunk 3.78s >> * ant 3.97s >> * mvn2 4.27s >> * mvn3 5.17s >> * gradle0.8 7.74 >> >> 2. Using our multi-project benchmark build >> - 25 projects >> - 100 source and test classes >> - Test reports disabled, no parallel test execution >> >> clean build, fastest to slowest: >> * ant 14.77s >> * gradle0.8 28.58s >> * gradle daemon 30.24s >> * gradle trunk 35.33s >> * mvnsh 40.15s >> * mvn3 41.99s >> >> build when everything up-to-date, fastest to slowest: >> * gradle daemon 2.5s >> * gradle trunk 5.84s >> * ant 10.12s >> * mvnsh 14.68s >> * mvn3 22.85s >> * gradle0.8 24.68s >> >> There are also a lot of interesting things we can do in the future if we >> have a long running process to do them in. Here are some initial >> possibilities: >> - check for updates to snapshots and download in the background, so that >> they are ready for the next build (even better if the repository >> managers could push changes to us). >> - configure the project model, build buildSrc, compile scripts, etc in >> the background >> - garbage collect all the various caches we leave lying around on the >> file system >> - use file system change notifications (java 7 and/or native notifiers) >> to watch for out-of-date source files >> >> It's also a step towards providing remote and/or distributed builds and >> testing. >> >> I've added a prototype to the 'build_daemon' branch. Please try it out >> if you want. You just run the 'gradle' command as per normal, and the >> daemon is automatically started as needed. There are a couple of >> command-line options if you want to control this: >> >> gradle --stop >> stops the daemon >> gradle --nodaemon >> runs the build without using the daemon >> gradle --foreground >> runs the daemon, in the foreground. For debugging. >> >> It generally works fine. There are a few broken things: >> - exit code from 'gradle' is always 0 >> - error handling is pretty rough >> - the console stuff (test counters, etc) don't work >> - stderr and stdout are merged >> >> Once 0.9 is out, I'd like to merge this into a 0.9.1 release. >> >> >> -- >> Adam Murdoch >> Gradle Developer >> http://www.gradle.org >> CTO, Gradle Inc. - Gradle Training, Support, Consulting >> http://www.gradle.biz >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > >
-- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
