Сравнение скорости - Процедурные и ОО в устных переводах

В интерпретируемых языках программирования, таких как PHP и JavaScript, каковы последствия использования объектно-ориентированного подхода по сравнению с процедурным подходом?

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

Итог: насколько велика (если таковая имеется) производительность в действительности, если использовать OO против Procedural на интерпретируемом языке?

7 ОТВЕТОВ
РЕШЕНИЕ

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

Вы ударяете ноготь по голове, когда говорите «ремонтопригодность». Я бы выбрал подход, который является наиболее продуктивным и наиболее обслуживаемым. Если вам нужна скорость позже, это не произойдет от переключения между процедурными и объектно-ориентированными парадигмами кодирования в интерпретируемом языке.

17
6.08.2008 03:36:28
У меня был босс из ада. Он ничего не знал о программировании, но думал, что знает все (однажды он читал мне лекции по меткам времени Unix, говоря: «Метки Unix похожи на европейские метки времени. Они делают это странно, сначала они ставят день, а затем месяц как этот: dd»). / мм / гггг "РОФЛ, какой идиот). Поэтому, когда он узнал, что я использую OO PHP, он отключился и сказал, что это «замедлит наш сайт». Я искал какое-либо исследование, которое смог найти, чтобы доказать, что он полон его, чтобы я мог продолжать программировать OO ...
cmcculloh 24.08.2009 16:47:55
ООП является менее продуктивным и менее обслуживаемым.
Pablo Ariel 18.12.2016 18:21:44
@cmcculloh Да, в Европе это первый день в году дд / мм / гггг, в основном самый маленький до самого большого, а в Китае это гггг / мм / дд, который является самым большим вплоть до самого маленького. Очевидно, что это единственные способы, которые логически имеют смысл.
Hasen 11.03.2019 05:33:27
Хм, забавная аналогия, для меня это не имеет смысла, может быть легко выбрать цвет сарая в конце, это не влияет на общий дизайн сарая. Переключение кодовой базы между процедурным и ОО-стилями является сложным, это почти потребует полного переписывания кода.
ericcurtin 19.03.2020 13:52:34

Итог: нет, потому что накладные расходы на интерпретацию превышают накладные расходы на диспетчеризацию методов.

4
6.08.2008 03:42:09

Если вы используете устный перевод, разница не имеет значения. Вы не должны использовать интерпретируемый язык, если производительность является проблемой. Оба будут работать примерно одинаково.

1
6.08.2008 03:49:20

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

Так что действительно, это не имеет значения (по моему опыту в любом случае).

0
26.08.2008 20:01:09

Ваше выступление будет характеризоваться реализацией, а не языком. Вы можете использовать самый медленный язык, и он может стать самым большим сайтом в мире, если вы создадите его в масштабе.

Просто запомните первое правило оптимизации.

Не.

:)

1
22.09.2008 18:18:17

К сожалению, я тоже сделал свои тесты. Я проверил скорость, и она примерно такая же, но при тестировании использования памяти, получая memory_get_usage () в PHP, я увидел значительно большее число на стороне ООП.

116 576 байт для ООП и 18 856 байт для процедурного. Я знаю, «Аппаратные средства дешево», но давай! 1000% увеличение использования? Извините, это не оптимально. И так как много пользователей одновременно попадают на ваш сайт, я уверен, что ваша память просто сгорела или закончилась. Я ошибся?

10
22.07.2011 21:28:14

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

ООП требует намного больше выделения памяти (MALLOC) и намного больше операций для выполнения в памяти, чем процедурный код. Это требует гораздо больше процессорного времени для выполнения своих задач. По сути, это «накладные расходы», обернутые вокруг процедурного кода, увеличивающие нагрузку на процессор при его выполнении, особенно при выполнении операций с базой данных.

Многим программистам нравится удобство ООП, создавая маленькие черные ящики, скрытые за простыми интерфейсами. Тем не менее, мне хорошо заплатили за то, что я оживил сайты, которые постоянно реагировали на запросы пользователей. Удаление ООП и замена его простыми процедурными функциями имело огромное значение.

Если вы не ожидаете, что ваш сайт будет очень занят, обязательно используйте ООП. Если вы строите систему с высоким трафиком, вам нужно убрать каждый цикл ЦП из обработки и каждый байт из выходных данных, которые вы можете.

2
22.03.2015 19:31:03