Упс, там идет производительность? - PullRequest
3 голосов
/ 19 февраля 2009

Я работал над своим сайтом, написанным на php / mysql. Когда я впервые написал это, это были спагетти с большим количеством php, встроенных в html и тому подобное - очень трудно поддерживать.

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

Но при тестировании производительности сайта с использованием webwait и осады, новая, более структурированная версия, кажется, работает и загружается медленнее, чем версия спагетти-кода.

Разница во времени загрузки составляет почти 1 секунду - 2,39 с против 3,81 с

Ничего другого не изменилось, кроме кода php - ни js, ни css

Так в чем здесь проблема? Должен ли я вернуться к старому коду? Это случилось с другими?

Edit:

  • Я провел некоторый анализ, используя cachegrind, в том числе и я думаю код довольно хороший.
  • Я тоже знаю, что проблема не совсем Упс, но большая структура и т. Д. а также, что ООП вообще не гарантировать лучшую производительность.
  • Я тоже запускал код несколько раз.
  • Я использовал cachegrind с kcachegrind, включая осаду (большая часть инструменты Rasmus Lerdorf изложены в его drupalcon 2008 говорит о 'Простой Тяжело ')

Я хочу знать, как другие справляются с этим.

Ответы [ 7 ]

14 голосов
/ 19 февраля 2009

«Должен ли я вернуться к старому коду?»

Если я скажу «вернуться», вы скажете: «Понимаете, я знал, что ОО был взорван, никто не может сделать ОО-приложение, которое работает». Это было бы неправильно.

Если я скажу «не возвращаться», вы скажете: «но это недопустимо медленно».

Итак, что осталось?

Вы должны написать это лучше . Иди вперед. Перепишите свой ОО, чтобы он действительно работал. ОО не "магия" - ничего не гарантирует. Есть плохие ОО программы и хорошие ОО программы. В вашем случае у вас явно есть возможности для улучшения.

Так что возьмите несколько инструментов профилирования производительности и узнайте, куда ушло время.

Кроме того, не «оптимизировать» - переписать.

Скорее всего, у вас есть какой-то поиск, который занимает много времени. Устранить поиск. Используйте лучшие контейнеры и коллекции (хеш-карты, наборы и т. Д.)

6 голосов
/ 19 февраля 2009

Профилируйте код. Я не знаю, как это сделать в PHP, но это единственный разумный способ понять, что происходит.

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

1 голос
/ 25 февраля 2009

Я могу придумать пару моментов для рассмотрения:

  • Это не выбор ООП против спагетти-кода. Существуют и другие парадигмы, которые могут быть такими же обслуживаемыми и структурированными, как ООП, но с другими характеристиками производительности. Можно написать код ООП, используя только простые функции процедурного языка (многие большие C-фреймворки используют стиль очень ООП-эй.) В некоторых случаях более функциональный стиль также может быть проще. ООП не единственная истинная парадигма.
  • Существуют разные степени ООП. Моделирование данных как объектов в большинстве языков не вызывает заметной разницы в производительности (хотя я не знаю, как PHP работает в этой области, но с PHP я всегда ожидаю худшего). Однако виртуальные функции, наследование (и особенно множественное наследование) работают медленнее и создают дополнительные издержки, которых часто можно было бы избежать. Какие функции ООП вы используете? Существует ли более простой дизайн ООП, который бы справлялся с этой задачей, но с меньшей зависимостью от «медленных» языковых функций?

Кроме того, обычно применяется обычное (вы можете оптимизировать алгоритм, включить кэширование или прекомпиляцию и т. Д., - хотя они могут существенно помочь, они не относятся к ООП)

1 голос
/ 19 февраля 2009

Попробуйте настроить Xdebug и посмотреть, что он может вам сказать. Кто-то еще упомянул, что вы должны проверить это с помощью профилировщика. Я согласен, и Xdebug может предоставить вам один, а также некоторые другие полезные функции. Ваша IDE может даже интегрироваться с Xdebug.

1 голос
/ 19 февраля 2009
There's a difference of nearly 1 second in loading time - 2.39s vs 3.81s

Это разница 3,81-2,39 = 1,42 с, что составляет более 50% от меньшего значения, поэтому, на мой взгляд, это не малое число. Проводили ли вы свои тесты несколько раз, чтобы начальная стоимость компиляции / интерпретации была правильно амортизирована? Рассматривали ли вы попытку ввести таймеры, чтобы увидеть, где отводится больше времени, чем раньше? Это были бы мои предложения, так как, кажется, вы ввели много абстракций и теперь видите цену за это.

0 голосов
/ 19 февраля 2009

ООП означает много вызовов функций, а вызовы функций в динамических языках медленные. Таким образом, «перевод» старого кода в версию ООП замедлит его. Сделайте полную переписать.

0 голосов
/ 19 февраля 2009

Следует учитывать одну вещь: используете ли вы APC или какое-либо другое решение для кэширования кода операции PHP? Если нет, весь ваш код будет интерпретироваться с нуля каждый раз, когда вы загружаете страницу. Это может определенно повлиять на производительность.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...