2010-10-22 5 views
5

Ich habe eine Rails 2.3.8 App mit einer Aktion, die eine große Menge von Daten aus einer Datenbank abruft und sie mit irgendwo zwischen 300-600 Teilbildern rendert (rekursiv Rendern einer Baumstruktur). Das Benchmarking einer Anfrage ergibt Antwortzeiten von ca. 7 Sekunden.Ruby 1.9 langsamer als Ruby 1.8?

Ich dachte, dass ein Upgrade meiner Ruby-Version auf 1.9 von 1.8 mir eine Leistungssteigerung bringen würde, aber wenn ich die 1.9-Version benchmarkiere, bekomme ich Antwortzeiten von etwa 9 Sekunden (2 Sekunden langsamer als bei 1.8). Das war ziemlich überraschend für mich.

Welche Faktoren würden dazu führen, dass Ruby 1.9 langsamer als Ruby 1.8 ausgeführt wird?

Unten ist ein Teil der Protokolldatei.

Rubin 1,8

Rendered family_index/descendants/_fi_hover (0.5ms) 
Rendered family_index/descendants/_descendant (4.6ms) 
Rendered search/_search_div (0.1ms) 
Rendered family_index/descendants/_fi_hover (0.7ms) 
Rendered family_index/descendants/_descendant (4.7ms) 
Rendered search/_search_div (0.1ms) 
Rendered family_index/descendants/_fi_hover (0.5ms) 
Rendered family_index/descendants/_descendant (4.5ms) 
Rendered family_index/descendants/_fi_hover (0.5ms) 
Rendered family_index/descendants/_descendant (37.9ms) 
Rendered family_index/surname_groups/_pedigree (3162.9ms) 
Rendered shared/_headers (4.6ms) 
Rendered shared/_new_messages (0.6ms) 
Rendered shared/_home_logo (1.1ms) 
Rendered shared/_login_box (4.0ms) 
Rendered shared/_navigation (13.6ms) 
Rendered shared/_flash_messages (0.8ms) 
Rendered shared/_footer (1.0ms) 
Rendered shared/_analytics (0.8ms) 
Completed in 4552ms (View: 3352, DB: 147) | 200 OK [http://localhost/family_index/surname_groups/31] 

Rubin 1,9

Rendered family_index/descendants/_fi_hover (0.3ms) 
Rendered family_index/descendants/_descendant (1.9ms) 
Rendered search/_search_div (0.1ms) 
Rendered family_index/descendants/_fi_hover (0.4ms) 
Rendered family_index/descendants/_descendant (2.0ms) 
Rendered search/_search_div (0.1ms) 
Rendered family_index/descendants/_fi_hover (0.3ms) 
Rendered family_index/descendants/_descendant (1.9ms) 
Rendered family_index/descendants/_fi_hover (0.3ms) 
Rendered family_index/descendants/_descendant (15.1ms) 
Rendered family_index/surname_groups/_pedigree (762.8ms) 
Rendered shared/_headers (2.6ms) 
Rendered shared/_new_messages (0.7ms) 
Rendered shared/_home_logo (0.9ms) 
Rendered shared/_login_box (3.6ms) 
Rendered shared/_navigation (7.3ms) 
Rendered shared/_flash_messages (0.7ms) 
Rendered shared/_footer (0.8ms) 
Rendered shared/_analytics (0.6ms) 
Completed in 5736ms (View: 942, DB: 128) | 200 OK [http://localhost/family_index/surname_groups/31] 

Es scheint, dass Ruby 1.9 ist die Ansichten Rendering und die Verarbeitung der Datenbank schneller, aber ist die Vollendung noch die Anfrage langsamer.

Ruby 1.8:

Completed in 4552ms (View: 3352, DB: 147) | 200 OK [http://localhost/family_index/surname_groups/31] 

Ruby 1.9:

Completed in 5736ms (View: 942, DB: 128) | 200 OK [http://localhost/family_index/surname_groups/31] 

aktualisieren 10-26-2010

ich den Engpass in meinem Code gefunden habe. Es kommt von einer Zeile, die eine Tonne von ActiveRecord-Elementen mit den faulen geladenen Verknüpfungen lädt. Die DB-Zeit ist klein, aber ich vermute, dass die gesamte Objektzuteilung einen Tribut fordert. Hier ist mein Verein:

has_many :deep_branches, 
      :class_name => "FamilyIndex::Branch", 
      :include => { 
       :descendant => [:state, :county, {:wives => {:marriage => [:state,:county,:reference] }}, :reference, { 
       :children => [:state, :county, {:wives => {:marriage => [:state,:county,:reference] }}, :reference, { 
        :children => [:state, :county, {:wives => {:marriage => [:state,:county,:reference] }}, :reference, { 
        :children => [:state, :county, {:wives => {:marriage => [:state,:county,:reference] }}, :reference] # add marriages to this data 
        }] 
       }] 
       }] 
      } 

Ohne den eifrigen Laden zu tun, die ganze Aktion dauert etwa 40 Sekunden abgeschlossen, so dass die Verwendung von: include gibt etwa 10-facher Leistungssteigerung. Ich suche immer noch nach einer Möglichkeit, dies zu beschleunigen. Vielleicht ist Caching der einzige Weg von hier aus zu gehen.

+0

hängen von Ihrem Code ab. Was ist Ihr Code und Sie können sagen, ob es Botteneck oder nicht – shingara

+0

Im Allgemeinen wurde Ruby 1.9 in Bezug auf die Leistung verbessert. Ich denke, Sie müssen etwas Code zeigen. – jwueller

+0

zu viel Code zum Posten, aber ich glaube, dass die Antwort von Sepp2k auf einen großen Teil meiner Leistungsprobleme hinweist. –

Antwort

2

Der Bereich meiner Anfrage, der am längsten verarbeitet werden musste, war die massive Datenbelastung durch ActiveRecord's faul eager loading (siehe die in der Frage aufgeführte Verbindung). Ich bin mit den Interna von ActiveRecord 2.3.8 nicht genug vertraut, so dass ich mir letztlich nicht sicher bin, was die "Langsamkeit" verursacht hat.

Ich endete meine eigene Art von eifrigen Laden-holen alle Personen Datensätze in einer Abfrage, alle Zustände in einer Abfrage, und andere zugehörige Objekte, die ich brauchte, legte sie in einen Hash und dann sie zusammen in ihren Baum Struktur.

Dies hat die Leistung stark verbessert und die Anforderungszeit auf 1-1,5 Sekunden verkürzt. Die Verbesserung wirkt sich positiv auf die App aus, die sowohl in Version 1.8 als auch in Version 1.9 läuft, und jetzt ist meine App in Version 1.9 etwas schneller.

Vielen Dank für Ihre Hilfe!

7

Ein Bereich, in dem 1,9 langsamer als 1,8 sein kann, ist die String-Verarbeitung.

Seit 1.9 hat die richtige Unicode-Unterstützung Indizierung oder ein Slicing eine Unicode-codierte Zeichenfolge kann als in 1,8 deutlich länger dauern, weil in 1,8 string[i] wird nur das i te Byte zurückgeben, während in 1.9 es durch den Strang gehen zu finden das i th Zeichen.

Wenn Sie viel String-Handling betreiben und keine korrekte Unicode-Unterstützung benötigen, können Sie die Codierung einfach auf ASCII oder möglicherweise binär setzen, was die String-Handhabung erheblich beschleunigen sollte.

+0

Ich wette, das ist es. Ich habe viele String-Splitting-Operationen, was sicherlich die Performance beeinflussen würde. Ich brauche die Unicode-Unterstützung nicht, also setze ich die Kodierung auf ASCII und sehe was passiert. –

+2

@Jimmy, bitte melde dich mit deinen Befunden zurück. –

+0

Ich habe in die Codierung der App eingecheckt, und die Codierung ist US-ASCII, also glaube ich nicht, dass es das Codierungsproblem ist, das ich zuvor vermutet habe. Ich habe einige Auszüge aus meinen Protokolldateien hinzugefügt, wenn das hilft. –