Когда я начал изучать Python, я создал несколько приложений без классов (только функции), теперь я знаю классы и знаю, что код будет много читабельным (и понятным), когда я буду переписывать его с помощью классов.
Будет ли код намного медленнее, если я буду использовать классы вообще?
Нет.
В целом вы не заметите разницы в производительности, основанной на использовании классов или нет. Различные подразумеваемые кодовые структуры могут означать, что один быстрее, чем другой, но невозможно сказать, какой из них.
Всегда пишите код, который нужно читать, тогда, если и только если он не достаточно быстро сделает его быстрее. Помните: Преждевременная оптимизация - это корень всего зла.
Чтобы ответить на вопрос: да, это, вероятно, будет немного медленнее, при прочих равных условиях. Некоторые вещи, которые раньше были переменными (включая функции), теперь будут объектными атрибутами, а self.foo всегда будет немного медленнее, чем foo, независимо от того, был ли foo глобальным или локальным. (Доступ к локальным переменным осуществляется по индексу и глобальным именам по имени, но поиск атрибутов на объекте - это локальный или глобальный поиск, а также дополнительный поиск по имени для атрибута, возможно, в нескольких местах.) Вызов метода также немного медленнее, чем вызов функции - не только медленнее получить атрибут, но и медленнее выполнять вызов, потому что метод является объектом-оболочкой, который вызывает написанную вами функцию, добавляя дополнительные служебные служебные вызовы.
Будет ли это заметно? Обычно нет. В редких случаях это может быть, скажем, если вы получаете доступ к атрибуту объекта много (тысячи или миллионы раз) в определенном методе. Но в этом случае вы можете просто назначить self.foo локальной переменной foo в верхней части метода и ссылаться на нее по локальному имени в целом, чтобы восстановить 99,44% преимуществ локальной производительности.
Вкратце: будет вероятный незначительный удар по производительности, и когда поражение в производительности будет больше, чем незначительное, его легко смягчить. С другой стороны, вы могли бы сэкономить часы в письменной форме и поддерживать код, предполагая, что ваша проблема поддается объектно-ориентированному решению. И экономить время, вероятно, почему вы используете язык, такой как Python, чтобы начать с.
Возможно, вам все равно, как вы думаете.
На самом деле.
Конечно, код с классами может быть немного медленнее по косвенности. Может быть. Для чего предназначена компиляция JIT, верно? Я никогда не могу вспомнить, какие версии python делают это, а какие нет, потому что:
Производительность не имеет значения.
Как минимум постоянные отличия в производительности. Если вы не выполняете множество вычислений (вас нет!), Вы потратите больше времени на разработку/отладку/поддержку вашего кода. Оптимизируйте для этого.
Действительно. Потому что вы никогда не сможете измерить разницу, если вы не находитесь в узком круге. И вы не хотите делать это на python в любом случае, если вам не очень важно время. Это не похоже на то, что вы пытаетесь сбалансировать свой segway на питоне, не так ли? Вы просто хотите вычислить некоторые цифры, не так ли? Ваш компьютер действительно хорош в этом. Доверяйте этому.
Тем не менее, это не означает, что классы - это путь. Просто эта скорость не является вопросом, о котором вы должны спрашивать. Вместо этого попытайтесь выяснить, какое представление будет лучшим для вашего кода. Кажется, теперь вы знаете классы, вы будете писать чистый код в стиле OO. Преуспевать. Учить. Итерация.
Дональд Кнут, один из великих старых умов вычислительной техники, заслуживает внимания: "Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация - корень всего зла". Решение использовать процедурные методы, а не объектно-ориентированные на основе увеличения скорости, которые, возможно, вообще не будут реализованы, не является разумной стратегией.
Если ваш код работает и его не нужно изменять, не стесняйтесь оставлять его в покое. Если это необходимо изменить, то вы должны рассмотреть разумный рефакторинг для включения классов, поскольку читаемость программы гораздо важнее скорости во время разработки. Вы также увидите преимущества в улучшенной ремонтопригодности. По-прежнему применяется старая пила от Kernighan и Plauger "Элементы стиля программирования":
Во-первых, заставьте его работать. Затем (если он не работает достаточно быстро), он работает быстрее.
Но, прежде всего, идите на удобочитаемость. Серьезно.