On Jun 10, 2009, at 7:50 PM, Paul Gier wrote:
We're currently using Maven for a lot of our projects at JBoss and
I've been researching Gradle a bit to see if it can solve some
problems in our builds. I set up one of our simple builds to use
Gradle just to check it's performance vs. Maven, and I was kind of
surprised to see that Gradle seemed somewhat slower for the build.
The project is a basic java/jar project and I am using the gradle
"java" plugin. In Maven this is equivalent to a "jar" packaging.
So running a clean build
gradle clean libs ~ 12s
mvn clean package ~ 8s
gradle libs ~ 10 - 20s (This one varied quite a bit while testing)
mvn package ~ 5s
Maven builds seem significantly slower in general than Ant builds,
so I was hoping that Gradle would be somewhere in between. So
anyway, my question is mainly (1) whether performance is a known
problem with Gradle and it's being worked on,
The performance of a build tool has a couple of aspects. One is its
execution efficiency. The other is its smartness in not doing
unnecessary actions.
I don't think there are major usability issues with Gradle's execution
efficiency. On the other hand we haven't focused on optimizing that in
the last releases. I was doing some profiling recently and found a
significant inefficiency in some areas were we use reflection. The fix
is now in trunk and has a very nice impact on the performance.
I use the Apache Abdera project (which is a 28 projects multi-project
build) as my guinea pig project for comparisons.
gradle clean libs -Dskip.test takes 15 seconds on my machine. (Gradle
trunk)
mvn clean package -o takes 20 seconds. (Maven 2.1)
gradle libs -Dskip.test takes 7 seconds on my machine. (Gradle trunk)
mvn package -o takes 9 seconds. (Maven 2.1)
So this is looking very good I think. There are more optimizations
that can be done to improve execution efficiency. We definitely need
to figure out why the testing takes so much longer than with Ant. Its
funny that Maven has the same problem.
Another area were we want to improve Gradle in not doing unnecessary
stuff. Having a good change detection and act on this accordingly,
etc ....
(2) maybe Gradle just has a slow startup time and with bigger
projects it's not an issue, (3) maybe I'm doing/not doing something
that is making the build slower.
I obviously didn't do any detailed test, but I did notice that in my
small build the steps that seem to take the most time are the
initial startup, the test task, and the jar task.
How do I tell Gradle to fork once for the tests instead of the
default per test forking?
test {
options.fork(forkMode: ForkMode.ONCE)
}
or
test.options.fork(forkMode: ForkMode.ONCE)
Also I remember reading something in the user guide about pre
compiling the build script, how do I do that?
This is done automatically for you. The precompiled script can be
found in the project's .gradle directory.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
