Come trovi le parti meno ottimizzate di un programma?

Question

Esistono strumenti per fornire una sorta di istogramma in cui viene trascorsa la maggior parte del tempo di esecuzione del programma?

Questo è per un progetto che utilizza c ++ in Visual Studio 2008.

Answer 1

Il nome che stai cercando è un profiler . Prova Trova colli di bottiglia dell'applicazione con Visual Studio Profiler

Answer 2

È necessario un profiler .

Visual Studio Team Edition include un profiler (che è quello che stai cercando) ma potresti avere accesso solo alle versioni Professional o Express. Dai un'occhiata a questi thread per le alternative:

Qual è il tuo strumento di profilazione preferito (per C ++) Quali sono alcuni buoni profiler per C ++ nativo su Windows?

Non dovresti davvero ottimizzare QUALSIASI parte della tua applicazione fino a quando non avrai misurato il tempo necessario per l'esecuzione. Altrimenti potresti indirizzare gli sforzi nel posto sbagliato e potresti peggiorare le cose, non meglio.

Answer 3

Ho usato un profiler chiamato " AQ Time " che fornisce ogni dettaglio che desideri conoscere sulle prestazioni del tuo codice. Non è gratuito però ..

Answer 4

Potresti ottenere un istogramma del contatore del programma, ma è praticamente inutile a meno che tu non stia facendo qualcosa di stupido come passare il tempo in una sorta di bolla di una vasta gamma di ints o doppi.

Se fai qualcosa di semplice come una sorta di bolla di una matrice di stringhe, l'istogramma del PC ti dirà solo che hai un hotspot nella routine di confronto delle stringhe. Non è di grande aiuto, vero?

So che non faresti una sorta di bolla del genere, ma solo per divertimento, supponiamo che tu l'abbia fatto e che il 90% del tempo è passato. (ad esempio, se lo hai risolto, potrebbe andare fino a 10 volte più veloce.)

In realtà è una cosa molto facile da trovare, perché se premi il pulsante Pausa nel debugger, quasi sicuramente vedrai che si ferma nella routine di confronto delle stringhe. Quindi se cerchi lo stack di un livello, guarderai direttamente il ciclo di ordinamento delle bolle che è il tuo bug. Se non sei sicuro di aver davvero individuato il problema, basta metterlo in pausa più volte. Il numero di volte che vedi il problema ti dice quanto è costoso.

Qualsiasi riga di codice che appare nello stack di chiamate in multiple è qualcosa che ti sta implorando di risolverlo. Alcuni non puoi, come " chiama _main " ;, ma se puoi otterrai una buona velocità, garantita.

Quindi fallo ancora e ancora.

Quando finisci le cose che puoi sistemare, allora hai davvero messo a punto il programma nel giro di un centimetro della sua vita.

È così semplice.

---

Puoi anche usare il profiler in Visual Studio. È uno strumento carino ma fai attenzione a queste carenze:

• Confonderti con "tempo esclusivo", che se ti concentri su informazioni a livello di linea, è quasi insignificante.

• Se il tuo programma sta perdendo tempo a fare I / O, non lo vedrà, perché quando smette di fare I / O, i campioni si fermano, a meno che tu non usi la strumentazione.

• Ma se usi la strumentazione, non otterrai informazioni a livello di linea, ma solo a livello di funzione. Va bene se le tue funzioni sono tutte piccole.

• Ti confonde con il "quot tree di chiamata". Ciò che conta per una riga di codice è il numero di campioni dello stack su cui si trova. Se si trova in molti rami dell'albero di chiamata, l'albero di chiamata non ti mostrerà quanto costa realmente.

• Se ti dice che una linea è costosa, non può dirti perché. Per questo vuoi vedere tutte le informazioni sullo stato di ogni campione di cui hai bisogno, piuttosto che solo dei riassunti.

• È difficile dirlo quando vuoi fare dei campioni e quando no. Vuoi che venga campionato quando stai aspettando l'app, non quando ti sta aspettando.

Answer 5

Quindi ora che sai di aver bisogno di un profiler, potresti non avere quello di Visual Studio, quindi Very Sleepy potrebbe essere di aiuto.