Una definición de "punto caliente" es una región de código donde el contador de programa pasa una buena fracción de su tiempo. Un término relacionado es "cuello de botella" que, si bien está mal definido, generalmente se refiere al código localizado en una función, rutina o método, que provoca que se gaste una fracción de tiempo superior a la necesaria.
Ambos términos son muy engañosos, porque hay una gran suposición no escrita. Se supone que no hay oportunidades para acelerar un programa que no sea un punto de acceso o un cuello de botella. Las oportunidades de aceleración pueden ser más difusas que eso, y si no se encuentran y se arreglan, se convierten en el limitador de rendimiento.
Déjeme dar un ejemplo. Recientemente, cuando trabajaba en un programa C++ de aproximadamente 300 líneas, tomé diez stackshots, porque quería ver cómo podía acelerarlo. Cuatro de esos stackshots era la siguiente:
CTypedPtrArray<CPtrArray,COperation *>::operator[]() line 1555 + 23 bytes
TcProcess() line 246 + 14 bytes ---> COperation* pOp = oplist[i];
CMhAck::Handler() line 165
doit() line 297 + 12 bytes
main() line 318
CTypedPtrArray<CPtrArray,CJob *>::operator[]() line 1555 + 23 bytes
SchProcess() line 212 + 14 bytes ---> pJob = joblist[i];
COpAck::Handler() line 145
doit() line 297 + 12 bytes
main() line 318
CTypedPtrArray<CPtrArray,CTask *>::operator[]() line 1555 + 23 bytes
TcProcess() line 249 + 18 bytes ---> pTask = pOp->tasks[pOp->iCurTask];
CMhAck::Handler() line 165
doit() line 297 + 12 bytes
main() line 318
CTypedPtrArray<CPtrArray,CTask *>::operator[]() line 1555 + 23 bytes
COperation::~COperation() line 57 + 15 bytes ---> CTask* p = tasks[i];
COperation::`scalar deleting destructor'() + 37 bytes
TcProcess() line 259 + 28 bytes
CTskAck::Handler() line 193
doit() line 297 + 12 bytes
main() line 318
El programa tardó 20 segundos en general. Lo que estas muestras de pila me dicen es que aproximadamente el 40% de ese tiempo, u 8 segundos, se gasta en el operador de indexación de la clase de matriz. Eso me dice que podría reducir el tiempo de ejecución de 20 segundos a 12 segundos, dar o recibir, si pudiera indexar más directamente, no a través de una llamada a función. La aceleración sería 20/12 = 1,67, o aproximadamente un 67% de aceleración. (Aviso: No me importa un bledo "exacta" cuando se trata de tiempo Lo que quería hacer era encontrar el problema ..)
Ahora uno puede estar en desacuerdo con facilidad con ese método de solucionar el problema , pero se puede ver cómo detecté cuál era el problema, ¿verdad?
Bien, entonces, ¿dónde está el "punto de acceso" y dónde está el "cuello de botella"? Claramente, hay un punto de acceso en la función del operador de indexación, pero ¿es ahí donde está el problema? (En realidad ni siquiera es eso, porque son tres funciones diferentes.) ¿Eso significa que debería intentar hacer esa rutina más rápido? ¡Ni siquiera lo tengo!
¿Hay un cuello de botella en la forma de alguna "rutina lenta"? ¡No! No hay una rutina particular que sea lenta o un "mal algoritmo".
Lo que hice fue hacer una descripción de lo que estaba haciendo ("Está indexando en ciertas rutinas.") Donde esa descripción se aplica una gran parte del tiempo.
El mejor término que se me ocurre para estas cosas es "agotar el tiempo", porque se está gastando una gran parte del tiempo haciendo cosas que no realmente hay que hacer.
More about terminology and popular misconceptions.
Una pregunta para los programadores de pila? – Wivani