Starten Ruby-App schrecklich langsam aufgrund erfordert von GEM_HOME

Question

Ich arbeite derzeit an einer Ruby-Anwendung, aber es läuft sehr (sehr!) Langsam .. Bis jetzt habe ich ein paar Dinge ausprobiert und ich könnte eingrenzen Es geht um das Hauptproblem: Ruby versucht in jedem einzelnen Verzeichnis in $ LOAD_PATH nach den benötigten Daten zu suchen.

Grundsätzlich, was ich beobachte, ist, dass Ruby durch eine Los von Dateien sucht, um zu sehen, ob es dort existiert gibt. Falls es sie nicht finden sollte, wird es zum nächsten Verzeichnis in der Zeile gehen. Das Schöne ist, dass ich das mit Strace erleben kann. Es gibt eine Menge von Ausgabe wie folgt:

open("/boa_proj_build/nsteen/.gem/gems/i18n-0.7.0/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/thread_safe-0.3.5/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/tzinfo-1.2.2/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/minitest-5.8.2/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/activesupport-4.2.4/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/climate_control-0.0.3/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/cocaine-0.5.7/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/boa_loggable-0.2.2/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/ruby_expect-1.6.0/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/cctools-3.0.1/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/git-1.2.9.1/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/naught-1.1.0/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/symbolizer-0.0.1/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/settingslogic-2.0.9/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/memoist-0.12.0/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/highline-1.7.8/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 
open("/boa_proj_build/nsteen/.gem/gems/commander-4.3.5/lib/commander/help_formatters/base.rb", O_RDONLY|O_CLOEXEC) = 8 

Wie Sie sehen können, ist es durch einige Verzeichnisse sucht es Anforderungen zu finden.

dies mit einer Testanwendung Tracing, Filtern für die ENOENT Fehler und das Vorkommen zählt, zeigt die folgende in Bezug auf Leistung:

vdi9442:/boa_proj_build/nsteen/$ strace packager --version 2>&1 | grep ENOENT | wc -l 
3454261 

of-natürlich 3,5 Millionen ist viel. Und dies wird zu einer Ladezeit von etwa 5 Minuten (und etwa die Hälfte ohne Strace) führen, bevor es seine Versionsnummer ausgeben wird (Standardfunktionalität vom Commander-Juwel).

Ich habe meine gesamte Heimatverzeichnis entfernt, und führte den Test erneut, und es ist sofort schneller, aber ich sehe es durch diese paar Edelsteine ​​(Abhängigkeiten wie Commander) wieder, aber "nur" ein paar tausend Vorkommen statt 3,5 Mil.

Mein Juwel env sieht wie folgt aus:

- GEM PATHS: 
    - /boa_proj_build/nsteen/.gem 
    - /home/nsteen/.gem/ruby/2.1.0 
    - /cadappl/ruby/2.1.1/ruby/lib/ruby/gems/2.1.0 

Es sieht aus wie Rubin nur durch meine gesamte Lastpfad zu Fuß, um einige Abhängigkeiten zu erfüllen. Es ist in Ordnung, aber das wird nur lächerlich. Hat jemand eine Ahnung was los ist? Dies kann nicht gewollt werden/Standardverhalten, das ich vermute?

Hat jemand eine Ahnung was los ist? Und wie kann ich die Dinge beschleunigen?

Answer 1

Es gibt durchaus ein paar Möglichkeiten, mit diesem einschließlich gemrc Dateien umgehen, die ich nicht in erhalten. Ich werde ein paar der Optionen erwähnen Sie haben:

Lösung 1:

Die andere Antwort ist richtig, aber ich wollte etwas zu diesem Thema erweitern, da es eine ist, dass die Menschen von Angesicht zu oft scheinen . RVM kann helfen. Eine besondere Eigenschaft ist dafür gemacht, Edelsteine. Ich persönlich bin nach Rbenv gezogen und habe nicht zurückgeschaut. Rbenv ist viel weniger aufdringlich für Ihre Umgebung als RVM, aber beide sind großartig. Sie können sowohl in RVM als auch in rbenv Gemsets verwenden, um zu begrenzen, welche Edelsteine ​​für Ihre App verfügbar sind. Sie können auch einen App-spezifischen Edelsteinsatz erstellen. Mit einem Edelstein-Set sucht Ihre App an einem Ort und lädt nur Edelsteine, die sie benutzt hat. Es wird nicht mit anderen Apps kombiniert. Das Beste daran ist automatisch, Sie müssen es nur einmal einrichten und es wird automatisch wechseln, wenn Sie in diesem Verzeichnis sind.Es ist auch mit Rubymine und anderen IDEs/Editoren integriert, die Ruby unterstützen.

Lösung 2:

Set GEM_PATH Umgebungsvariable auf einen der Standorte. Das überschreibt alles andere, so dass es zumindest an mehreren Stellen aufhört zu suchen.

Lösung 3 (Application Ladeoptimierung):

Etwas, das Sie in, wenn Sie bundler verwenden aussehen könnte ist, können Sie nur auf spezielle Edelsteine ​​Verwendung erfordern, wenn sie gebraucht werden. wenn Sie die Bordsteinkante Juwel in einem Modul des App verwenden, fügen Sie diese zum Beispiel zu Anfang der Datei Ihres Modul laden:

require 'curb' 

und Ihre Gemfile ändern, so dass die Linie Laden Bordsteinkante wie folgt aussehen:

Je weniger Edelsteine ​​geladen werden, wenn Ihre App startet, desto schneller wird sie geladen. Die Auto-Require-Funktion ist großartig, wird aber oft vergessen und als selbstverständlich angesehen. Es ist erstaunlich, welchen Unterschied es machen könnte.

Answer 2

Ich würde vorschlagen, rvm für Ruby-Version und Edelstein-Management zu verwenden. Mit rvm können Sie anwendungsspezifische Gemsets und Ruby-Versionen erstellen.

Ich hoffe, dass dies Ihr Problem lösen wird.

https://rvm.io/