2010-10-22 4 views
5

У меня есть приложение Rails 2.3.8 с действием, которое вытаскивает большой объем данных из базы данных и отображает его где угодно от 300-600 партикулов (рекурсивно рендеринг структуры древовидного типа). Сравнительный анализ одного запроса дает мне время отклика около 7 секунд.Ruby 1.9 медленнее, чем Ruby 1.8?

Я думал, что обновление моей версии Ruby до 1,9 от 1,8 даст мне прирост производительности, но, сравнивая версию 1.9, я получаю время отклика около 9 секунд (на 2 секунды медленнее, чем на 1,8). Это было для меня совершенно неожиданно.

Какие факторы могут привести к тому, что Ruby 1.9 будет работать медленнее, чем Ruby 1.8?

Ниже приведена часть файла журнала.

рубин 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] 

рубин 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] 

Оказывается, что Ruby 1.9 является предоставление мнения и ускорения обработки базы данных, но по-прежнему завершает запрос медленнее.

Рубин 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] 

Update 10-26-2010

Я нашел узкое место в моем коде. Он исходит из строки, которая загружает тонну элементов ActiveRecord, используя ленивые загруженные ассоциации. Время БД мало, но я предполагаю, что все распределение объектов забирает плату. Вот моя ассоциация:

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

Не делая жадную загрузку, полное действие занимает около 40 секунд, чтобы закончить, поэтому с помощью: включить дает об увеличении в 10 раз производительности. Все еще ищут способ ускорить это. Возможно, кеширование - это единственный путь отсюда.

+0

зависит от вашего кода. Каков ваш код, и вы можете сказать, есть ли боттенек или нет. – shingara

+0

В целом, Ruby 1.9 был улучшен с точки зрения производительности. Я думаю, вам нужно будет показать какой-то код. – jwueller

+0

слишком много кода для публикации, но я считаю, что ответ sepp2k указывает на большую часть моих проблем с производительностью. –

ответ

2

Таким образом, область моей просьбы, которая занимала много времени для обработки, - это массовая загрузка данных с помощью ленивой нетерпеливой загрузки ActiveRecord (см. Ассоциацию, указанную в вопросе). Я недостаточно знаком с внутренними компонентами ActiveRecord 2.3.8, поэтому в конечном счете я не уверен, что вызывало «медленность».

Я закончил тем, что сделал все возможное, чтобы загружать все записи людей в один запрос, все состояния в одном запросе и другие связанные с ним объекты, которые мне нужны, помещая их в хэш, а затем сшивая их вместе в свое дерево состав.

Это значительно улучшило производительность, доведя время запроса до 1-1,5 секунд. Улучшение выгодно для приложения, работающего в 1,8 и 1,9, и теперь мое приложение немного быстрее работает в 1,9.

Спасибо всем за вашу помощь!

7

Одна область, где 1.9 может быть медленнее, чем 1,8, является обработка строк.

С 1.9 имеет правильную индексацию поддержки юникода или нарезка строка в Юникоде может занять значительно больше времени, чем в 1,8, потому что в 1.8 string[i] будет просто вернуть i-й байт, в то время как в версии 1.9 он должен пройти через строку, чтобы найти i-й символ.

Если вы выполняете большую обработку строк и не нуждаетесь в надлежащей поддержке юникода, вы можете просто установить кодировку в ASCII или, возможно, двоичную, что должно значительно ускорить обработку строк.

+0

Держу пари, это все. У меня много операций по разделению строк, что, безусловно, повлияет на производительность. Мне не нужна поддержка юникода, поэтому я поставлю кодировку в ASCII и посмотрю, что произойдет. –

+2

@ Джимми, пожалуйста, сообщите о результатах. –

+0

Я проверил кодировку приложения, а кодировка - US-ASCII, поэтому я не думаю, что это проблема кодирования, которую я подозревал раньше. Я добавил некоторые отрывки из моих файлов журналов, если это поможет. –