Будет ли использование меньшего количества обращений к функциям увеличивать скорость общего выполнения? [Дубликат]

Question

Будет ли использование меньшего количества обращений к функциям увеличивать скорость общего выполнения? [Дубликат]

1

Возможный дубликат:
Создает ли отдельные функции вместо одного большого медленного времени обработки?

Ооп Блуп!

Да, OOP отлично, держит код чистым и хорошо организованным. Вот почему я люблю его использовать. Я имею в виду OOP очень примитивно в использовании функций (defs).

Извлечет мои вызовы функций и приклеивает содержимое функции прямо к моему algo, увеличит скорость выполнения всего кода? Да, я знаю, что могу сам пройти тест, но я решил задать его здесь на форуме моих коллег-коллег-кодеров, потому что я знаю, что это вопрос, который плавает во многих головах....

def myFunc(var):
   return var*3243 #perhaps more complicated function code will make a difference?

i = 0
hungry = True
while hungry:
  i = i + 1
  x = myFunc(i)
  if i > 50:
     hungry = False

drinkice 04 май 2011, в 03:57

Источник

1

Предположим, что компилятор умнее вас.
Greg Hewgill 04 май 2011, в 01:31
1

«Да, я знаю, что могу провести тест самостоятельно». Пожалуйста пожалуйста пожалуйста. Сначала запустите тест самостоятельно, чтобы мы знали, о чем вы на самом деле говорите. Мы можем предположить много случайных вещей, мы не знаем, что вы предполагаете.
S.Lott 04 май 2011, в 01:35
1

Вы вводите свой вопрос с концепцией ООП, но ваш вопрос не имеет ничего общего с ООП. Или, если это так, вы должны уточнить это.
Lynch 04 май 2011, в 01:36
2

@ Феликс Клинг: Интересно то, что ответ на этот вопрос, по крайней мере, частично неверен.
Swiss 04 май 2011, в 01:40
0

Речь идет не о конкретном фрагменте кода, а об общем поведении вызовов функций в зависимости от скорости кода. Это может быть применимо к любой ситуации, когда скорость выполнения очень важна. Неоднозначность имеет целью сделать вопрос более открытым, а ответы более полезными для всех, кто их ищет.
drinkice 04 май 2011, в 01:42
2

@drinkice: «Неоднозначность целеустремленна», но также делает вопрос просто бессмысленной перефразировкой потенциальных компромиссов, и может быть, может быть, может иметь и обычно. Пожалуйста, предоставьте что-то конкретное, чтобы была возможность получить фактический, фактический ответ.
S.Lott 04 май 2011, в 01:45
2

@ Грег Почему? Компилятор не может ничего предположить. Учитывая имеющуюся информацию, часто не разрешается вносить значительные изменения в целях повышения производительности. Особенно в таких динамических языках, как Python. Какой-то совершенно другой модуль может потенциально импортировать этот модуль, а затем изменить myFunc во время работы программы. Учитывая наши базовые знания, этого не произойдет. Но компилятор не обладает такими знаниями. Ясно, что мы умнее , чем компилятор.
Ponkadoodle 04 май 2011, в 01:49

Показать ещё 5 комментариев

Теги:

python

3 ответа

Ещё вопросы

Предположим, что компилятор умнее вас.
«Да, я знаю, что могу провести тест самостоятельно». Пожалуйста пожалуйста пожалуйста. Сначала запустите тест самостоятельно, чтобы мы знали, о чем вы на самом деле говорите. Мы можем предположить много случайных вещей, мы не знаем, что вы предполагаете.
Вы вводите свой вопрос с концепцией ООП, но ваш вопрос не имеет ничего общего с ООП. Или, если это так, вы должны уточнить это.
@ Феликс Клинг: Интересно то, что ответ на этот вопрос, по крайней мере, частично неверен.
Речь идет не о конкретном фрагменте кода, а об общем поведении вызовов функций в зависимости от скорости кода. Это может быть применимо к любой ситуации, когда скорость выполнения очень важна. Неоднозначность имеет целью сделать вопрос более открытым, а ответы более полезными для всех, кто их ищет.
@drinkice: «Неоднозначность целеустремленна», но также делает вопрос просто бессмысленной перефразировкой потенциальных компромиссов, и может быть, может быть, может иметь и обычно. Пожалуйста, предоставьте что-то конкретное, чтобы была возможность получить фактический, фактический ответ.
@ Грег Почему? Компилятор не может ничего предположить. Учитывая имеющуюся информацию, часто не разрешается вносить значительные изменения в целях повышения производительности. Особенно в таких динамических языках, как Python. Какой-то совершенно другой модуль может потенциально импортировать этот модуль, а затем изменить myFunc во время работы программы. Учитывая наши базовые знания, этого не произойдет. Но компилятор не обладает такими знаниями. Ясно, что мы умнее , чем компилятор.

ncoghlan · Answer 1 · 2011-05-04T04-15-00.000Z

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

PyPy использует функцию inline и сортирует другие трюки в своем компиляторе Just-In-Time, чтобы ускорить выполнение кода, не делая его недостижимым в названии скорости.

Обратите внимание, что это решение работает только в том случае, если вы используете Python 2.x с любыми поддерживаемыми вами расширениями C, которые вы используете, совместимыми с cpyext.

Swiss · Answer 2 · 2011-05-04T00-05-00.000Z

2

По-видимому, в Python накладные расходы очень высоки.

http://wiki.python.org/moin/PythonSpeed/PerformanceTips#Data_Aggregation

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

Swiss 04 май 2011, в 00:05

0

У меня просто была революционная идея ... В большинстве простых ситуаций я просто использую функции, чтобы просто сделать код проще для чтения, особенно функции, которые содержат большие куски кода. Если использование ООП и вызовов функций предназначено исключительно для лучшего визуального представления, это должна быть работа используемой вами IDE или визуального редактора кода, а не изменение способа работы вашего кода (с использованием ООП, функций и т. Д.)
drinkice 04 май 2011, в 02:18
0

то есть: кто-то должен создать процедурный дружественный редактор кода, который позволяет минимизировать куски кода (не обязательно те, которые заключены в скобки или отступы), шлепать имя, чтобы определить, что делает этот кусок кода, а затем минимизировать его, таким образом удовлетворяя организационные потребности и сделать код более легким для чтения (таким образом, легче отлаживать, редактировать и т. д.
drinkice 04 май 2011, в 02:18
0

таким образом, вам не нужно будет ООП-кодировать свой код (жертвуя скоростью), чтобы получить лучший визуальный внешний вид, код уже достаточно ответственен (функциональность), нам не нужно добавлять работу с хорошим визуальным отображением в наш "набор инструкций "(код), и манипулировать им постоянно, это задача для наших инструментов визуального редактирования
drinkice 04 май 2011, в 02:20
0

Я думаю, это то, что в конечном итоге делает компилятор, хотя мы можем видеть, что он не всегда делает это так, как нам хотелось бы (без встроенных функций в python ...?)
drinkice 04 май 2011, в 02:24
0

@ Drinkice: «Я думаю, это то, что в конечном итоге делает компилятор», поправьте. Ничего революционного в этом нет. Если вы хотите эту функциональность, прекратите использовать Python и используйте C ++, Java или C # или аналогичные.
S.Lott 04 май 2011, в 03:34

Показать ещё 3 комментария

John La Rooy · Answer 3 · 2011-05-03T23-41-00.000Z

Python не будет "встроить" эту функцию для вас, поэтому, конечно, есть накладные расходы. Обычно код в функции занимает достаточно времени, чтобы служебные данные вызова были незначительными.

Имейте в виду, что гораздо проще тестировать, отлаживать и профилировать программы, разбитые на функции.

Если вам действительно нужна более высокая производительность, обычно лучше написать функцию в C или Cython, чем устранить служебные данные вызова

Также стоит отметить, что обычный код, созданный таким образом

def main():
   ...

if __name__=="main":
    main()

быстрее, чем просто запуск кода на верхнем уровне, поскольку поиск идентификаторов выполняется быстрее в функциях/методах, чем в глобальном пространстве имен