В интерпретируемых языках программирования, таких как PHP и JavaScript, каковы последствия использования объектно-ориентированного подхода по сравнению с процедурным подходом?
В частности, я ищу контрольный список вещей, которые следует учитывать при создании веб-приложения и выборе между процедурным и объектно-ориентированным подходами, чтобы оптимизировать не только скорость, но и удобство обслуживания. Цитируемые исследования и контрольные примеры также могут быть полезны, если вам известны какие-либо статьи, исследующие эту тему далее.
Итог: насколько велика (если таковая имеется) производительность в действительности, если использовать OO против Procedural на интерпретируемом языке?
Может быть, я сумасшедший, но беспокоиться о скорости в подобных случаях, используя интерпретирующий язык, все равно, что пытаться выяснить, какой цвет красить сарай. Давайте даже не будем вдаваться в мысль, что этот вид оптимизации является полностью преждевременным.
Вы ударяете ноготь по голове, когда говорите «ремонтопригодность». Я бы выбрал подход, который является наиболее продуктивным и наиболее обслуживаемым. Если вам нужна скорость позже, это не произойдет от переключения между процедурными и объектно-ориентированными парадигмами кодирования в интерпретируемом языке.
Итог: нет, потому что накладные расходы на интерпретацию превышают накладные расходы на диспетчеризацию методов.
Если вы используете устный перевод, разница не имеет значения. Вы не должны использовать интерпретируемый язык, если производительность является проблемой. Оба будут работать примерно одинаково.
На самом деле я провел небольшой тест, подобный этому, в python на веб-сайте, который я поддерживаю, и обнаружил, что они почти эквивалентны по скорости, с процедурным подходом, выигрывающим что-то вроде десятитысячных долей секунды, но код OO был настолько значительным Я не продолжал упражнение дольше, чем одна итерация.
Так что действительно, это не имеет значения (по моему опыту в любом случае).
Ваше выступление будет характеризоваться реализацией, а не языком. Вы можете использовать самый медленный язык, и он может стать самым большим сайтом в мире, если вы создадите его в масштабе.
Просто запомните первое правило оптимизации.
Не.
:)
К сожалению, я тоже сделал свои тесты. Я проверил скорость, и она примерно такая же, но при тестировании использования памяти, получая memory_get_usage () в PHP, я увидел значительно большее число на стороне ООП.
116 576 байт для ООП и 18 856 байт для процедурного. Я знаю, «Аппаратные средства дешево», но давай! 1000% увеличение использования? Извините, это не оптимально. И так как много пользователей одновременно попадают на ваш сайт, я уверен, что ваша память просто сгорела или закончилась. Я ошибся?
По моему опыту, сайт, находящийся под большой нагрузкой, будет перегружен и с помощью ООП-кода станет гораздо проще отвечать на запросы, чем процедурный. Причина проста для понимания.
ООП требует намного больше выделения памяти (MALLOC) и намного больше операций для выполнения в памяти, чем процедурный код. Это требует гораздо больше процессорного времени для выполнения своих задач. По сути, это «накладные расходы», обернутые вокруг процедурного кода, увеличивающие нагрузку на процессор при его выполнении, особенно при выполнении операций с базой данных.
Многим программистам нравится удобство ООП, создавая маленькие черные ящики, скрытые за простыми интерфейсами. Тем не менее, мне хорошо заплатили за то, что я оживил сайты, которые постоянно реагировали на запросы пользователей. Удаление ООП и замена его простыми процедурными функциями имело огромное значение.
Если вы не ожидаете, что ваш сайт будет очень занят, обязательно используйте ООП. Если вы строите систему с высоким трафиком, вам нужно убрать каждый цикл ЦП из обработки и каждый байт из выходных данных, которые вы можете.