¿Crear funciones separadas en lugar de una grande, lento, tiempo de procesamiento?

Estoy trabajando en el entorno y la progtwigción de Google App Engine en Python. Estoy creando una función que esencialmente genera un número aleatorio / cadena de letras y luego las almacena en 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. 

¿La creación de dos funciones en lugar de una grande afecta el rendimiento? Prefiero dos, ya que coincide mejor con lo que pienso, pero no me importa combinarlos si eso es “la mejor práctica”.

Concéntrese en poder leer y entender fácilmente su código.

Una vez que haya hecho esto, si tiene un problema de rendimiento, analice qué podría estar causándolo.

La mayoría de los idiomas, incluido Python, tienden a tener gastos generales bastante bajos para hacer llamadas a métodos. Poner este código en una sola función no va a cambiar (dramáticamente) las métricas de rendimiento. Supongo que su generación de números aleatorios probablemente será la mayor parte del tiempo, no teniendo 2 funciones.

Dicho esto, las funciones de división tienen un impacto (muy, muy pequeño) en el rendimiento. Sin embargo, lo pensaría de esta manera: puede llevarte de ir a 80 mph en la carretera a 79.99 mph (lo que nunca notarás). Lo importante a tener en cuenta es evitar los semáforos y los atascos de tráfico, ya que harán que tenga que detenerse por completo …

En casi todos los casos, las funciones de “alineación” para boost la velocidad es como hacerse un corte de cabello para perder peso.

Reed tiene razón. Para el cambio que está considerando, el costo de una llamada de función es una pequeña cantidad de ciclos, y tendría que hacerlo 10 ^ 8 o más veces por segundo antes de que se dé cuenta.

Sin embargo, me gustaría advertir que a menudo la gente va al otro extremo, y entonces es como si las llamadas a funciones fueran costosas. He visto esto en sistemas sobre-diseñados donde había muchas capas de abstracción.

Lo que sucede es que hay una psicología humana que dice que si algo es fácil de llamar, entonces es rápido. Esto lleva a escribir más llamadas de funciones que las estrictamente necesarias, y cuando esto ocurre en múltiples capas de abstracción, el desperdicio puede ser exponencial.

Siguiendo el ejemplo de conducción de Reed, una llamada de función puede ser como un desvío, y si el desvío contiene desvíos, y si también contienen desvíos, pronto se pierde mucho tiempo, sin ninguna razón obvia , porque cada llamada de función parece inocente.

Como han dicho otros, no me preocuparía por eso en este escenario en particular. La pequeña sobrecarga involucrada en las llamadas de función palidecería en comparación con lo que se hace dentro de cada función. Y mientras estas funciones no sean llamadas en rápida sucesión, probablemente no importe mucho de todos modos.

Aunque es una buena pregunta. En algunos casos, es mejor no dividir el código en múltiples funciones. Por ejemplo, cuando se trabaja con tareas intensivas de matemáticas con bucles nesteds, es mejor hacer el menor número posible de llamadas de función en el bucle interno. Esto se debe a que las operaciones matemáticas simples en sí mismas son muy baratas, y además de eso, la función de llamada de sobrecarga puede causar una penalización de rendimiento notable.

Hace años, descubrí que la función de hipotensión (hipotenusa) en la biblioteca matemática que estaba usando en una aplicación VC ++ era muy lenta. Me pareció ridículo porque es un conjunto de funciones tan simple – return sqrt (a * a + b * b) – ¿qué tan difícil es eso? Así que escribí el mío y logré mejorar el rendimiento en 16X. Luego agregué la palabra clave “en línea” a la función y la hice 3 veces más rápida que eso (alrededor de 50 veces más rápido en este punto). Luego saqué el código de la función y lo puse en mi propio bucle y vi otro pequeño aumento de rendimiento. Entonces … sí, esos son los tipos de escenarios en los que puedes ver una diferencia.