Начальные вопросы ООП

Это во многом зависит от фактического алгоритма, который вы пытаетесь реализовать, и от компилятора (за последние годы они стали очень умными). Скомпилированный код точно не будет побайтно идентичен, а может быть и совсем другим (опять же, зависит от алгоритма, который вы реализуете). На самом деле, это не имеет значения.

В большинстве случаев разница в скорости программы будет незначительной, если только вы не делаете что-то крайне неэффективное в той или иной форме (и это, скорее всего, будет связано с вашей бизнес-логикой и алгоритмами, которые вы будете использовать). реализовать его, а не парадигму программирования), это не будет проблемой.

Другое, часто игнорируемое, но решающее различие в скорости заключается в удобстве сопровождения: компьютерное время в большинстве случаев стоит дешево; время программиста дорого. (Это не означает «писать вирусы», а скорее «не тратить неделю на выяснение того, как это работает, когда кому-то еще нужно обновить логику через три года»)

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

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

В основном, моя точка зрения такова: выигрыш от наличия кода, который легче читать, повторно использовать и поддерживать, легко оправдает небольшую потерю производительности (если таковая имеется), большую часть время.

Все языки производят один и тот же код, как и ASM (машинный код), кроме языков, создающих байт-код (например, Java) или интерпретируемых языков (например, Python, PHP)

Всегда есть компромисс между эффективностью и ремонтопригодностью.

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

В конце концов, ООП или нет, собственные компиляторы будут генерировать ASM-код, или виртуальная машина будет генерировать байт-коды (для JIT-компиляторов). Важно не смешивать парадигму ООП с скомпилированным кодом; компьютеру все равно, как организован код, и он все равно выполнит его. Конечно, после компиляции процедурный код будет отличаться от кода ООП.Однако я бы не стал говорить, что ООП — это просто «о том, как вы пишете код», просто потому, что производительность процедурного приложения всегда будет снижаться быстрее по мере расширения проекта, чем у ООП.

Весь код в конечном итоге сводится к машинному коду. Существуют только определенные способы представления данных в памяти. Я бы предположил, что код ASM полностью зависит от компилятора и от того, выполняете ли вы оптимизацию. Для языков, компилируемых с помощью байт-кода, исходный код компилируется в байт-код, а затем обрабатывается интерпретатором. Может даже существовать компилятор JIT (Just-In-Time), который компилирует этот байт-код в собственный машинный код.

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

Если вас действительно волнует эффективность генерируемого кода, вам следует взглянуть на сами компиляторы и прочитать о том, какой код они генерируют. Большинство современных компиляторов выполняют всевозможные оптимизации (и вы даже можете указать им, какой уровень оптимизации вам нужен). Конечно, это в основном вступает в игру, когда вы программируете во встроенной среде.

Парадигма в основном не влияет на эффективность, но, конечно, некоторые языки более эффективны в определенных средах. C, например, очень хорошо работает во встроенной среде. Конечная цель состоит в том, чтобы выбрать правильный инструмент для работы. Например, я уверен, что вы могли бы использовать brainfck для написания встроенного кода, но brainfck — не очень удобный язык. Возможно, вам будет лучше с C.Если вы хотите заниматься встроенным программированием, но хотите использовать парадигму ООП, вы можете попробовать встроенный C++ или даже встроенный Java.

На самом деле, обычно объектно-ориентированный код приводит к чему-то (очень) немного медленнее. Причина этого в том, что объекты и классы имеют накладные расходы — даже несмотря на то, что фактический код становится процедурным, в фоновом режиме все еще происходят «вещи». Хорошее сравнение C и C++ можно найти здесь:

http://unthought.net/c++/c_vs_c++.html (посмотрите примерно на полстраницы или выполните текстовый поиск термина «Вполне разница! На 567%», если вы хотите сразу перейти к удивительному).

Это немного устарело, но все еще очень актуально. Однако в большинстве случаев прирост скорости не стоит дополнительного времени, необходимого для написания кода — это действительно экстремальный пример, и помните, что C — это язык очень низкого уровня; на самом деле я не знаю навскидку какой-либо другой язык, который бы так всесторонне превзошел C++ в прямом тесте скорости.

Также обратите внимание, что плохо написанный процедурный код почти всегда будет медленнее, чем хорошо написанный объектно-ориентированный код (думаю, кто-то уже упоминал об этом).

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

ООП обычно не быстрее/медленнее, чем процедурный. В любом случае это не имеет большого значения, учитывая, что наибольший прирост скорости достигается за счет выбора эффективных алгоритмов, а не оптимизации отдельных инструкций. А бенчмарки часто слишком спорны, чтобы иметь ценность.