Эффективность программы

Question

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

Answer 1

Может быть. Возможно нет.

Вы можете написать эффективный объектно-ориентированный код. Вы можете написать неэффективный структурированный код.

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

Используйте объектно-ориентированное программирование там, где имеет смысл его использовать, и структурированное программирование там, где имеет смысл его использовать. Вам не нужно выбирать между одним и другим: вы можете использовать оба.

Answer 2

Я помню, в начале 1990-х, когда C ++ был молодым, были исследования, посвященные этому. Если я правильно помню, ребята, которые взяли (хорошо написанные) программы на C ++ и перекодировали их в C, получили примерно 15% прирост скорости. Ребята, которые взяли программы на C и перекодировали их в C ++ и изменили императивный стиль C на стиль OO (но те же алгоритмы) для C ++, получили такую ​​же или лучшую производительность. Очевидное противоречие было объяснено наблюдением, что программы на Си, будучи переведенными в объектно-ориентированный стиль, стали лучше организованными. Вещи, которые вы делали в C, потому что кода было слишком много, и проблемы с улучшением выполнялись бы проще в C ++.

Вспоминая об этом, я удивляюсь заключению некоторых. Написание программы во второй раз всегда приведет к лучшей программе, поэтому она не должна быть обязательной для стиля ОО, который имеет значение. Сегодняшние компьютерные архитектуры разработаны с аппаратной поддержкой для общих операций, выполняемых ОО-программами, и компиляторы стали лучше использовать инструкции, поэтому я думаю, что вполне вероятно, что при любых накладных расходах, вызванных вызовом виртуальной функции в 1992 году, сегодня они намного меньше. 1003 *

Answer 3

Проблема не техническая, а психологическая. Это то, что побуждает вас делать это просто.

Чтобы сделать мирскую аналогию, это похоже на кредитную карту. Это гораздо эффективнее, чем выписывать чеки или использовать наличные. Если это так, то почему люди так часто сталкиваются с кредитными картами? Потому что ими так легко пользоваться, что они злоупотребляют ими . Требуется великая дисциплина, чтобы не злоупотреблять хорошей вещью.

Способ оскорбления ОО -

• Создание слишком большого количества "слоев абстракции"

• Создание слишком большой избыточной структуры данных

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

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

ДОБАВЛЕНО: В качестве иллюстрации того, что ОО поощряет, вот что я иногда вижу в настройке производительности: кто-то устанавливает SomeProperty = true;. Это звучит достаточно невинно, верно? Хорошо, что это может распространяться на объекты, которые содержат этот объект, часто через полиморфизм, который трудно отследить. Это может означать, что некоторому списку или словарю где-то нужно что-то добавить или удалить из него. Это может означать, что некоторый элемент управления дерева или списка нуждается в добавлении, удалении или перемещении элементов управления. Это может означать, что окна создаются или разрушаются. Это также может означать, что некоторые вещи необходимо изменить в базе данных, которая может быть не локальной, поэтому необходимо выполнить некоторые операции ввода-вывода или блокировки мьютекса.

Это может действительно сойти с ума. Но кого это волнует? Это аннотация .

Answer 4

Вы бы сказали «нет», если этот вопрос задан в статье по информатике.

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

Answer 5

Так не должно быть.Алгоритм это все вопросы.Я согласен, что инкапсуляция немного замедлит вас, но компиляторы помогут оптимизировать.

Answer 6

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

Answer 7

Может быть: подход ОО имеет тенденцию быть ближе к разъединенному подходу, когда разные модули не копаются друг в друге. Они ограничены общедоступными интерфейсами, и в этом всегда есть потенциальная стоимость. Например, вызов метода получения вместо простого исследования переменной; или вызов виртуальной функции по умолчанию, потому что тип объекта недостаточно очевиден для прямого вызова.

Тем не менее, есть несколько факторов, которые уменьшают это как полезное наблюдение.

1. Хорошо написанная структурированная программа должна иметь такую ​​же модульность (то есть скрывать реализации) и, следовательно, нести такие же издержки косвенного обращения. Стоимость вызова указателя функции в C, вероятно, будет очень похожа на стоимость вызова виртуальной функции в C ++.

2. Современные JIT и даже использование встроенных методов в C ++ могут устранить косвенные затраты.

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

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