2012-03-21 5 views
36

Obecnie przełączam się z ant na gradle dla mojej aplikacji internetowej w wielu modułach iw tej chwili wydaje się, że obecna wersja Gradle (M9) może być uruchomiona wbrew jej ograniczeniom. Ale może (mam nadzieję) to tylko problem z niezrozumieniem pojęć Gradle'a lub nieznajomością "przełącznika zwiększania mocy magicznej". Byłbym szczęśliwy z jakiejkolwiek wskazówki, jak można zoptymalizować wydajność budowania.Jak zoptymalizować wydajność kompilacji gradów pod względem czasu budowy i użycia pamięci RAM?

Problemy: kilka minut upłynąć, zanim zostanie wyświetlona pierwsza compileJava i nawet jeśli nic się nie zmieniło w źródłach, proces jest uruchomiony co najmniej 7 minut, aż się zawiesi w połowie :testClasses (w różnych podprojektów) z następującym komunikatem :

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

projekt składa się z około 30 (częściowo współzależne) podprojektach The build.gradle z nich jest mniej więcej takie same i są używane do tworzenia pliku słoik z każdej podprojekcie np

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

starałem się rozwiązać ten problem przestrzeń sterty przez rozkręceniu maksymalny rozmiar pamięci do 1024M, ale to nie pomogło. Mój główny plik build.gradle wygląda następująco:

  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

Czy zdarzy ci się być zastępując znaki? Stwierdziłem, że jest to jedna z rzeczy, która spowodowała, że ​​wieloprojektowy układ Gradle był wolniejszy o rząd wielkości, ponieważ zajmowaliśmy się zastępowaniem tokenów .gradle. –

+0

Dzięki za sugestię. Nie było jednak żadnych wymian. Odpowiedź Petera Niederwiesera pomogła:) – peterp

Odpowiedz

52

Trzeba dać więcej pamięci do Gradle JVM, a nie do zadań kompilacji/JVM. Jednym ze sposobów jest zmiana zmiennej środowiskowej GRADLE_OPTS (GRADLE_OPTS=-Xmx512m).

+3

Dzięki, ustawienie GRADLE_OPTS na -Xmx512m jako sugerowane nie tylko wyeliminowało błąd Heap Space, ale także znacznie przyspieszyło proces. Wykonanie kompilacji zajmuje sporo czasu, aw niektórych punktach nie jestem pewien, co robi Gradle w tle, ale mogę dalej używać profilera stąd :) – peterp

+0

Po ustawieniu na 512 otrzymuję ten sam błąd jeszcze raz; Ale kiedy ustawiam go na przykład na 2048, otrzymuję komunikat "Nie mogę zarezerwować wystarczającej ilości miejsca na 2097152". –

23

przypadku korzystania z Gradle Wrapper można ustawić DEFAULT_JVM_OPTS w gradlew tak:

DEFAULT_JVM_OPTS="-Xmx512m" 

Ustaw go w podobny sposób w gradlew.bat jeśli jesteś na Windows:

set DEFAULT_JVM_OPTS=-Xmx512m 

Zadaniem Gradle Wrapper można również zmodyfikować, aby uwzględnić to automatycznie. W ten sposób Gradle developers rozwiązali go:

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

Modyfikowanie zadania opakowania działa tak jak w przypadku Gradle 2.9 oraz – nerdherd

+0

Proponuję, aby przy podawaniu fragmentów kodu należało również podać informacje o plikach i ich ścieżki do plików. –

+0

Można to umieścić w dowolnym pliku kompilacji Gradle, o ile pamiętam. –

5

Właśnie znalazłem bardzo ładny sposób obsłużyć ten problem. Nie ma potrzeby stosowania niestandardowego wrappera ani GRADLE_OPTIONS.

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

Wykonaj Gradle z opcją --info, aby zobaczyć, w którym miejscu będzie używał twojego parametru dla maksymalnego rozmiaru pamięci.

gradle build --info 
4

W gradle.properties pliku dodaj następującą linię:

org.gradle.demon = true

To zwiększy build - zaczerpnięte z

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

+0

Wydaje się, że przeciążenie rozmiaru sterty java w punkcie, po chwili usunięto go, Myślenie o dysku SSD teraz jako następny etap wydajności –

+0

Demon gradle jest domyślnie włączony –

1

Żadna z powyższych odpowiedzi pracował dla mnie, a potem znalazłem this-

mojej konfiguracji systemu -

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

Opcje JVM do uruchamiania Gradle można ustawić za pomocą zmiennych środowiskowych. Możesz użyć GRADLE_OPTS lub JAVA_OPTS lub obu. JAVA_OPTS jest według konwencji zmienną środowiskową współużytkowaną przez wiele aplikacji Java. Typowym przykładem użycia byłoby ustawienie proxy HTTP w JAVA_OPTS i opcji pamięci w GRADLE_OPTS. Te zmienne można również ustawić na początku skryptu gradle lub gradlew.

dodałem niżej wymienione dwie zmienne środowiskowe i rozwiązać ten issue-

Variable Name: GRADLE_OPTS 
Variable Value: -Xmx512m 

Variable Name: JAVA_OPTS 
Variable Value: -Xmx512m 

Hope this helps do facetów takich jak ja.

3

Używam następujących wersji gradle.properties aby wydajność Gradle lepiej w Androidzie projektów

# 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

umieścić następującą zawartość do ~/.gradle jak 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

Włączenie demona gradle działa dobrze dla przyspieszenia gradle, ogólnie. Za każdym razem, gdy wywołujesz gradle, musi on załadować i przeanalizować plik kompilacji, a następnie może rozpocząć wykonywanie. Demon ładuje/parsuje i buforuje przeanalizowane dane. Następna inwokacja, jeśli plik kompilacji nie ulegnie zmianie, działa DUŻO szybciej. Nie powiedzie się jednak, jeśli kiedykolwiek "gradle --debug ", ponieważ próbujesz zobaczyć ścieżkę klasy, jakie wartości mają zmienne itp. Musisz wyłączyć demona w konfiguracji, zabić -9 proces NASTĘPNIE wykonaj: --debug THEN, po zakończeniu debugowania, włącz go ponownie w konfiguracji. – Meower68

2

osobiście przejrzał wszystkie artykuły tutaj, ale wykonanie tych kroków naprawiło to.

Jeśli używasz 32-bitowego jvm, może to być problem z instalacją 64-bitowego jvm.

  1. Przejdź do panelu sterowania (search java w oknach 10)
  2. wybrać aplikację Java
  3. podwójne kliknięcie na Java, a następnie wyświetlić.
  4. W przebiegu parametrów czasowych dodać:

    -Xmx 2048m 
    
+0

Dla każdego, kto szuka "parametrów wykonawczych", w W7 jest to pod zakładką "Java" po wykonaniu kroku 3, a następnie kliknij "Widok". Stamtąd "parametry czasu przebiegu" będą postrzegane jako jedna z komórek w siatce. – user1863152

+0

Dziękujemy! Miałem zainstalowaną 32-bitową i 64-bitową Javę, a gradle używał 32-bitowego zamiast 64-bitowego. – blk0ut

Powiązane problemy