2011-04-21 11 views
49

Rails 3.0 to poważny pies. Rozwijam się na Railsach od 5 lat i nigdy nie było wolniej. W szczególności testy trwają wiecznie, aby załadować bootstrap na najwyższym MacBooku z dyskiem SSD, więc cykle iteracji cierpią poważnie. Muszę przeczytać artykuł za każdym razem, gdy zaczynam test. To szalone, a nie "zwinne". Równie dobrze mógłbym się kompilować.Dlaczego bootstrap szyn jest tak wolny i co mogę z tym zrobić?

Jest to dla mnie główna motywacja, aby w końcu ruszyć z Rails - kiedy mam okazję.

Jeśli ktoś ma rozwiązanie, proszę go zaoferować. Wiem, że wiele osób cierpi z powodu tego problemu.

Nie używam rspec - Wiem, że istnieje rozwiązanie, które pomoże w testach dla rspec.

Używam quick_require i rails-dev-boost, ale nie ma znaczącego wpływu.

Mam ruby ​​1.9.2 i muszę być. Pojedynczy, bardzo prosty test kontrolera zajmuje 26 sekund na dwurdzeniowym MacBooku Air 2.13 Ghz z pamięcią 4 GB RAM i SSD! Czemu!?

+2

To samo tutaj. Jedną rzeczą, na którą warto spojrzeć, jest perftools.rb. https://github.com/tmm1/perftools.rb –

+0

Wygląda na to, że [ruby 1.9.3 znacznie przyspiesza ładowanie] (http: //www.rubyinside.com/ruby-1-9-3-szybsze ładowanie-razy-wymaga-4927.html). – hammar

+3

Spróbuj sprawdzić swoją ocenę akceptacji: p –

Odpowiedz

8

Cytując Yehuda Katz:

Są rzeczy, że C wymagają kod robi w 1,9 że powolne rzeczy na dół. Jednym z takich przykładów jest ponowne sprawdzenie $ LOAD_PATH, aby upewnić się, że wszystko jest rozszerzone na każde wymaganie. To jest coś, na co należy odpowiedzieć rubinowo. Otworzę bilet na Redmine, jeśli już go nie ma.

Występuje również ten problem, a problem $ LOAD_PATH wydaje się być potencjalną przyczyną. Miejmy nadzieję, że wkrótce zostanie naprawiony.

To brzmi dla mnie tak, jakbyś po prostu musiał cierpieć przez to i mam nadzieję, że zostanie naprawiony w Rubim 1.9.3.

+0

Dobre znalezisko. Odsyłacz: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/88519ef5a53088a1/c01ba447c6dc0de7?lnk=raot –

+0

Wygląda na to, że może być istotny (zdaję sobie sprawę, że zatwierdzenie ma prawie rok, ale ja wierzę, że nie jest to w 1.9.2). https://github.com/ruby/ruby/commit/2db572514cd9f5cc8957ab8f35f39650bb243ea7 Interesujące byłoby wypróbowanie "krawędziowej" kompilacji Rubiego, aby sprawdzić, czy problem został rozwiązany. – bratsche

+0

Z rvm zrobiłem szybkie porównanie ruby-1.9.2-p180 i ruby-head'a na "trasach rake" dla mojego obecnego projektu i odkryłem, że rubin-head był o około 16% szybszy. Nie było to jednak zbyt naukowe (i nie testowałem z 1.8.7, ponieważ ten projekt nie działa w wersji 1.8.7), ale może nadal jest interesujący. – bratsche

18

Zapoznaj się z spork. Zasadniczo uruchamia mały serwer, który uruchamia ładowanie, a następnie czeka na testy, co pozwala na bootstrap raz, a następnie wiele razy testować od tego stanu. Od czasu do czasu będziesz musiał go zrestartować, jeśli dokonasz pewnych zmian w konfiguracji, ale w przeważającej części pozwala ci to na bardzo szybkie iteracje red-green-refactor.

+1

Czy nie jest to tylko spp dla rspec? Używam test :: unit i shoulda. Również - ulepszenie w testowaniu pomaga, ale tak naprawdę nie rozwiązuje podstawowego problemu. –

+0

Istnieje [wersja testowa :: jednostka] (https://github.com/timcharper/spork-testunit). Zgadzam się, że to nie jest kompletne rozwiązanie, ale bardzo pomaga w tym przypadku użycia. – hammar

+0

Spork działa również z Test :: Unit. Pamiętaj tylko, że używając Sporks ma kilka "gotchas", skompilowałem listę linków, które pomogą ci je pokonać: https://gist.github.com/1118210 – arikfr

3

Jest to kompromis, aby zapłacić za nieprzedstawianie stwierdzeń "wymagaj". Railsy starają się postępować właściwie, a więc wstępnie ładują wszystko. Zasadniczo masz dwa rozwiązania:

  1. Używaj Wgrywanie bibliotekę spawns procesu poręcze (Spork na przykład)
  2. Nie używaj Rails w swoich badaniach, że wyciąg domenę można przetestować poza Rails (zniszczyć wszystkie Oprogramowanie ma jeden screencast na ten temat). Sprowadza się to do pomijania ładowanych szyn, jeśli to możliwe.

Z tym wszystkim, co powiedziałem, używając rozwiązania 1). i posiadające mój apartament uruchomić w pół sekundy (tylko 70 prób, ale waitng dla Rails na obciążenie jest minimalne)

7

problem wydaje się być powolność wymagać, jeśli nie pewne minimalne profilowanie jak

CPUPROFILE=/tmp/my_app_profile RUBYOPT="-r`gem which perftools | tail -1`" ruby -I lib:test test/unit/user_test.rb 
pprof.rb --text /tmp/my_app_profile 

prawdopodobnie powinieneś zobaczyć dużo czasu w wymaganiu (inną opcją jest zobaczenie go w ładowaniu urządzenia, ale domyślam się, że już wiesz, że to nie problem).

W moim pudełku (osx na MacBook Pro 2011 13 ", z rdzeniem i5 i obracającym się dyskiem twardym), czas jest bardziej podobny do 5 sekund, co jest nadal dużo, ale o wiele bardziej znośny, więc może to warto różnice dochodzenie.

Ile kamienie czy masz zainstalowane w systemie? Czy próbowałeś prowadzenie testów/uruchamianie bez Bundler/RubyGems?

+0

Jak mogę uruchomić testy bez bundlerów i rubygmatów? Są to zależności aplikacji i wszystkich testów. –

+0

powinieneś być w stanie rozpakować klejnoty u dostawcy/(bundler powinien wtedy ominąć globalne wyszukiwanie rubygm). Jeśli usuniesz plik gemfile niż bundler, nie powinieneś go używać w żadnym wypadku. Na koniec możesz skomentować linie w pliku config/boot.rb, które go wczytują/wywołać instalację i zastąpić je wymaganiami niestandardowymi. Przepraszam za późną odpowiedź. – riffraff

+0

Interesujące podejście. Zrobiłem "bundle - ścieżka dostawca /", a następnie "pakiet pakiet", jednak usunięcie odpowiednich linii z boot.rb nie może załadować pakowane klejnoty. Nie chciałbym usunąć mojego Gemfile, ponieważ chcę użyć bundler. –

3

Tak, to rediculously powolny. Oh wait, mvn install w moim Dni javy nigdy nie trwały mniej niż minutę, z mvn clean install było szalenie powolne, a szczęśliwe dni, pamiętając, zawsze podnoszą mojego ducha.

+1 spork, jak @hammar sugeruje

połączyć z guardhttps://github.com/guard/guard-test dla auto-uruchomieniem testów i masz zabójcze combo. Mieć to działa w jego własnym oknie i/lub ekranu i zobaczyć swoją produktywność w górę :)

Update/dodatek do odpowiedzi: końcówka

Optymalizacja: umieścić to_s na ścieżkach dodany do autoload_paths w environment.rb, unikanie tego ręcznego robienia tego w kółko. Może zgolić kilka sekund ...

2

Jak @ użytkownik185374 mówi, płacisz kompromis require.

natknąłem się na ciekawą resource przyspieszyć Rails testy bez użycia Rails ... Przykład podany jest z Rspec ale musisz logiki.

Oto jak autor podsumowuje:

Nie mogę powiedzieć, co to znaczy biec wszystkich moich ponad 150 specyfikacji w ciągu 2 sekund. Myślę, że to trochę dodatkowa praca, ale jest warta wysiłku!

Innym rozwiązaniem Właśnie znalazłem: Hydra równolegle do testowania:

http://logicalfriday.com/2011/05/18/faster-rails-tests-with-hydra/

+0

Czy zapomniałeś łącza? –

+0

Cholera, coś zepsułem :) poprawiono – apneadiving

2

Jest to znany problem, szczególnie w Rubim 1.9.2.

Dobrą wiadomością jest to, że jest a patch, co znacznie przyspiesza uruchamianie Ruby (require).

0

Dobra wiadomość. Railsy zaczynają się w znośnym czasie po uaktualnieniu do Ruby 1.9.3.

0

Zapoznaj się z zeus gem.

To powinno znacznie przyspieszyć działanie.

Powiązane problemy