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 > > >
