Делает ли создание отдельных функций вместо одной большой медленное время обработки?

Я работаю в среде Google App Engine и программирую на Python. Я создаю функцию, которая по сути генерирует случайную цифру / буквенную строку, а затем сохраняет в memcache.

def generate_random_string():
# return a random 6-digit long string

def check_and_store_to_memcache():
    randomstring = generate_random_string()
    #check against memcache
    #if ok, then store key value with another value
    #if not ok, run generate_random_string() again and check again.

Влияет ли создание двух функций вместо одной большой на производительность? Я предпочитаю два, так как они лучше соответствуют моим представлениям, но не против объединить их, если это "наилучшая практика".

 Bravery Onions05 июл. 2009 г., 00:44
Вы можете сделать отступ с 4 пробелами для правильного отображения кода.

Ответы на вопрос(4)

Почти во всех случаях "встраивание" Функции для увеличения скорости подобны стрижке, чтобы похудеть.

 06 июл. 2009 г., 16:49
++ Отличная метафора!
Решение Вопроса

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

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

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

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

 06 июл. 2009 г., 22:25
Хорошо сформулированный, Рид.
 05 июл. 2009 г., 13:34
Вы не упомянули, что преждевременная оптимизация создает больше проблем, чем решает.
 05 июл. 2009 г., 00:48
+1, очень хороший совет.
 04 мая 2011 г., 03:48
Я не согласен с вашим утверждением о том, что большинство языков, включая Python, имеют тенденцию к довольно низким накладным расходам на выполнение вызовов методов.wiki.python.org/moin/PythonSpeed/…
 06 июл. 2009 г., 22:16
Он действительно работал на солидной автомобильной аналогии. +1 за стиль!

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

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

Несколько лет назад я обнаружил, что функция гипотона (гипотенузы) в математической библиотеке, которую я использовал в приложении VC ++, была очень медленной. Мне это показалось смешным, потому что это такой простой набор функций - return sqrt (a * a + b * b) - насколько это сложно? Так что я написал свой и сумел улучшить производительность в 16 раз. Затем я добавил & quot; встроенный & quot; Ключевое слово для функции и сделал его в 3 раза быстрее (примерно в 50 раз быстрее). Затем я взял код из функции и поместил его в сам цикл и увидел еще одно небольшое увеличение производительности. Так что ... да, это те сценарии, в которых вы можете увидеть разницу.

 06 июл. 2009 г., 19:13
Не будет ли этоa+bб)

Рид прав. Для изменения, которое вы рассматриваете, стоимость вызова функции составляет небольшое количество циклов, и вам придется делать это 10-8 раз в секунду, прежде чем вы заметите.

Тем не менее, я хотел бы предупредить, что часто люди переходят в другую крайность, и тогда этоas if вызовы функций были дорогостоящими. Я видел это в чрезмерно спроектированных системах, где было много уровней абстракции.

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

Следуя примеру вождения Рида, вызов функции может быть как обходной путь, и если обходной путь содержит обходные пути, и если они также содержат обходные пути, вскоре теряется огромное время, так какobvious причина, потому что каждый вызов функции выглядит невинным.

Ваш ответ на вопрос