2012-03-21 16 views
36

Attualmente sto passando da ant a gradle per la mia applicazione web multi modulo e al momento sembra che la versione corrente di Gradle (M9) stia correndo contro i suoi limiti. Ma forse (si spera) è solo un mio problema non capire i concetti di Gradle abbastanza bene o non conoscere il "magico interruttore di potenziamento delle prestazioni". Sarei felice per qualsiasi suggerimento su come ottimizzare le prestazioni della build.Come ottimizzare le prestazioni di build gradle per quanto riguarda la durata della build e l'utilizzo della RAM?

I problemi: alcuni minuti passano prima che venga visualizzato il primo compileJava, e anche se nulla è cambiato nelle fonti, il processo è in esecuzione almeno 7 minuti fino a quando si blocca a metà strada attraverso :testClasses (a sottoprogetti variabile) con il seguente messaggio :

* What went wrong: 
Could not resolve all dependencies for configuration ':mysubproject_X:testRuntime'. 
> Java heap space 

il progetto consiste di circa 30 (in parte interdipendenti) sottoprogetti, il build.gradle dei quali è più o meno lo stesso e vengono utilizzati per creare un file jar da ogni sottoprogetto, es

sourceSets { 

    main { 
     java { 
      srcDirs 'src' 
     } 
    } 
} 

dependencies { 

    compile project(':mysubproject_A') 
    compile project(':mysubproject_B') 
    compile project(':mysubproject_E') 

    compile group: 'commons-lang', name: 'commons-lang', version: '2.2' 

} 

// copy all non-java files from src 
copy { 
    from sourceSets.main.java.srcDirs 
    into "$buildDir/classes/main" 
    exclude '**/*.java' 
} 

jar { 
} 

Ho provato a risolvere il problema dello spazio dell'heap aumentando la dimensione massima della memoria a 1024 M, ma non è stato di aiuto. Il mio file build.gradle principale appare così:

  sourceCompatibility = 1.6 
      version = 0.5 

      useFindBugs = false 

      apply plugin: 'java' 

      configurations { 
      } 

      repositories { 
       mavenCentral() 
       mavenRepo url:"http://repository.jboss.org/maven2", artifactUrls: ["https://repository.jboss.org/nexus/content/repositories/public","http://opensource.55minutes.com/maven-releases"] 
      } 


      dependencies { 
      } 

      buildscript { 
       repositories { 
        mavenRepo url: 'http://gradle.artifactoryonline.com/gradle/plugins' 
        flatDir(dirs: "$projectDir/lib") 
       } 

       dependencies { 
        classpath "org.gradle.plugins:gradle-idea-plugin:0.3.1" 
       } 
      } 

      subprojects { 
       apply plugin: 'java' 
       apply plugin: 'idea' 

       repositories { 
        mavenCentral() 
        mavenRepo url:"http://repository.jboss.org/maven2", artifactUrls: ["https://repository.jboss.org/nexus/content/repositories/public","http://opensource.55minutes.com/maven-releases"] 
       } 

       dependencies { 
        testCompile 'junit:junit:4.8.2' 
       } 

       compileJava { 
        options.encoding = 'UTF-8' 
        options.fork (memoryMaximumSize: '1024m') 
       } 

       javadoc { 
        options.encoding = 'UTF-8' 
       } 

       test { 
        testReportDir = file(rootProject.testReportDir) 
        forkEvery = 1 
        jvmArgs = ['-ea', '-Xmx1024m'] 
       } 
      } 


      dependsOnChildren() 

      task wrapper(type: Wrapper) { 
       gradleVersion = '1.0-milestone-9' 
      } 
+1

Ti capita di essere la sostituzione gettoni? Ho scoperto che questa è l'unica cosa che ha causato un aumento di Grado di un ordine di grandezza più lento perché stavamo sostituendo token con la cache .gradle. –

+0

Grazie per il tuo suggerimento. Tuttavia, non ci sono state sostituzioni coinvolte. La risposta di Peter Niederwieser sotto ha fatto il trucco :) – peterp

risposta

52

è necessario dare più memoria al Gradle JVM, non all'altezza del compito di compilazione/JVM. Un modo per farlo è tramite la variabile di ambiente GRADLE_OPTS (GRADLE_OPTS=-Xmx512m).

+3

Grazie, l'impostazione di GRADLE_OPTS a -Xmx512m come suggerito non solo ha eliminato l'errore Heap Space, ma ha anche velocizzato enormemente il processo. Ci vuole ancora un po 'di tempo per fare la build e in alcuni punti non sono proprio sicuro di cosa sta facendo Gradle in background, ma posso continuare a usare il profiler da qui :) – peterp

+0

Quando lo si imposta su 512, ottengo lo stesso errore ancora; Ma quando l'ho impostato su 2048152, ottengo "Impossibile riservare spazio sufficiente per 2097152" –

23

Se si utilizza il Gradle Wrapper è possibile impostare DEFAULT_JVM_OPTS in gradlew come questo:

DEFAULT_JVM_OPTS="-Xmx512m" 

Situato in un modo simile a gradlew.bat se siete su Windows:

set DEFAULT_JVM_OPTS=-Xmx512m 

Il compito Gradle Wrapper può anche essere modificato per includerlo automaticamente. Questo è come il Gradle developers hanno risolto:

wrapper { 
    gradleVersion = '1.8' 

    def jvmOpts = "-Xmx512m" 
    inputs.property("jvmOpts", jvmOpts) 
    doLast { 
     def optsEnvVar = "DEFAULT_JVM_OPTS" 
     scriptFile.write scriptFile.text.replace("$optsEnvVar=\"\"", "$optsEnvVar=\"$jvmOpts\"") 
     batchScript.write batchScript.text.replace("set $optsEnvVar=", "set $optsEnvVar=$jvmOpts") 
    } 
} 
+0

La modifica dell'attività del wrapper funziona come da Gradle 2.9 e – nerdherd

+0

Suggerisco che quando si forniscono frammenti di codice si dovrebbe anche indicare i problemi dei file e i loro percorsi di file. –

+0

Questo può essere inserito in qualsiasi file di build Gradle, per quanto mi ricordo. –

5

ho appena trovato un modo molto piacevole per gestire questo problema. Non è necessario il wrale gradle personalizzato o GRADLE_OPTIONS.

compileJava { 
    options.fork = true // Fork your compilation into a child process 
    options.forkOptions.setMemoryMaximumSize("4g") // Set maximum memory to 4g 
} 

Run Gradle con l'opzione di --info per vedere dove sta andando a utilizzare il parametro per la dimensione massima della memoria.

gradle build --info 
4

Negli gradle.properties del file aggiungere la seguente riga:

org.gradle.daemon = true

Questo aumenterà la build - tratto da

https://www.timroes.de/2013/09/12/speed-up-gradle/

+0

Sembra sovraccaricare la dimensione dell'heap java al punto, dopo un po 'di rimozione, Pensare al disco SSD per ora come fase successiva della prestazione –

+0

daemon gradle è abilitato per impostazione predefinita –

1

Nessuna delle risposte sopra funzionato per me, poi ho trovato questo-

mia configurazione del sistema -

Windows x64 - JDK 32 bit - Cordova 5.4.1 - Ionic 1.7.12 

opzioni JVM per l'esecuzione di Gradle possono essere impostate tramite variabili di ambiente. Puoi utilizzare GRADLE_OPTS o JAVA_OPTS o entrambi. JAVA_OPTS è per convenzione una variabile di ambiente condivisa da molte applicazioni Java. Un tipico caso d'uso sarebbe quello di impostare il proxy HTTP in JAVA_OPTS e le opzioni di memoria in GRADLE_OPTS. Queste variabili possono anche essere impostate all'inizio dello script gradlew o gradlew.

ho aggiunto i sotto indicati due variabili di ambiente e risolto questo problema-

Variable Name: GRADLE_OPTS 
Variable Value: -Xmx512m 

Variable Name: JAVA_OPTS 
Variable Value: -Xmx512m 

Spero che questo aiuti a ragazzi come me.

3

Sto usando seguente versione di gradle.properties per rendere le prestazioni Gradle meglio in Android proietta

# The Gradle daemon aims to improve the startup and execution time of Gradle. 
# When set to true the Gradle daemon is to run the build. 
org.gradle.daemon=true 

# Specifies the JVM arguments used for the daemon process. 
# The setting is particularly useful for tweaking memory settings. 
# Default value: -Xmx10248m -XX:MaxPermSize=256m 
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 

# When configured, Gradle will run in incubating parallel mode. 
# This option should only be used with decoupled projects. More details, visit 
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects 
org.gradle.parallel=true 

# Enables new incubating mode that makes Gradle selective when configuring projects. 
# Only relevant projects are configured which results in faster builds for large multi-projects. 
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:configuration_on_demand 
org.gradle.configureondemand=true 
1

mettere le seguenti contenuti per ~/.gradle come gradle.properties

# Project-wide Gradle settings. 
# IDE (e.g. Android Studio) users: 
# Settings specified in this file will override any Gradle settings 
# configured through the IDE. 
# For more details on how to configure your build environment visit 
# http://www.gradle.org/docs/current/userguide/build_environment.html 
# The Gradle daemon aims to improve the startup and execution time of Gradle. 
# When set to true the Gradle daemon is to run the build. 
# TODO: disable daemon on CI, since builds should be clean and reliable on servers 
org.gradle.daemon=true 
# Specifies the JVM arguments used for the daemon process. 
# The setting is particularly useful for tweaking memory settings. 
# Default value: -Xmx10248m -XX:MaxPermSize=256m 
org.gradle.jvmargs=-Xmx6g -Xms4g -XX:MaxPermSize=8g -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 
# When configured, Gradle will run in incubating parallel mode. 
# This option should only be used with decoupled projects. More details, visit 
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects 
org.gradle.parallel=true 
# Enables new incubating mode that makes Gradle selective when configuring projects. 
# Only relevant projects are configured which results in faster builds for large multi-projects. 
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:configuration_on_demand 
org.gradle.configureondemand=true 
+0

L'attivazione del demone gradle funziona bene per l'accelerazione gradle, in generale. Ogni volta che invochi gradle, deve caricare e analizzare il file di build, quindi può iniziare l'esecuzione. Il demone caricherà/analizzerà e memorizzerà nella cache i dati analizzati. La prossima chiamata, se il file di build non è cambiato, diventa MOLTO più veloce. Non riesce, però, se mai fai "gradle --debug " perché stai cercando di vedere il classpath, quali valori hanno le variabili, ecc. Devi disattivare il demone nella configurazione, kill -9 il processo ALLORA fai il --debug THEN, dopo aver completato il debug, riaccendilo nella configurazione. – Meower68

2

io personalmente ha esaminato tutti gli articoli qui ma facendo questi passaggi lo ha risolto.

Se si utilizza jvm a 32 bit, potrebbe essere necessario installare un jvm a 64 bit.

  1. Vai al pannello di controllo (ricerca java in Windows 10)
  2. trovare l'applicazione java
  3. Fare doppio clic su Java e quindi visualizzare.
  4. In parametri operativi aggiungere:

    -Xmx 2048m 
    
+0

Per chi cerca "parametri run-time", in W7 questo è nella scheda "Java" una volta eseguito il passaggio 3, quindi fare clic su "Visualizza". Da lì, i "parametri del tempo di esecuzione" verranno visualizzati come una delle celle nella griglia. – user1863152

+0

Grazie! Avevo installato Java a 32 bit e 64 bit e gradle usate a 32 bit anziché a 64 bit. – blk0ut

Problemi correlati