Informazioni su quanto tempo trascorso in una funzione, in base all'input di questa funzione [chiuso]

I tuoi test unitari dovrebbero coprire questo. Termina le chiamate in un cronometro e sei a posto.

Suppongo che tu non ne abbia poi, quindi ecco un modo per essere subito aggiornato e ottenere un po '.

Scrivi un test unitario parametrizzato sulla tua funzione usando Pex e poi eseguilo / quelle prove. Avere ANTS in esecuzione quando lo fai - o semplicemente impostare un cronometro prima / dopo la chiamata alla funzione.

In sostanza, se ricordo bene, Pex usa un dimostratore di teoremi per raggiungere ogni ramo e potenziale eccezione / condizione limite usando i parametri per la funzione. Controlla i parametri che genera, pensa in modo critico a qualcuno di tuo e dovresti avere quello che stai cercando.

In C ++, se questo è solo per un particolare metodo con input particolari, è piuttosto facile scrivere una classe helper che impiegherà quanto tempo ci vorrà per eseguire un particolare scope. Prendi il tempo nel costruttore e nel distruttore calcoli l'ora corrente e salvalo in una struttura dati statica.

Questa è una tecnica che ho usato con dispositivi embedded per i quali non avevo profiler.

Attenzione: non ho compilato / testato questo:

typedef std::map<std::pair<int,int>, std::pair<int,int> > timeMap;

class TimeIt {
private:
    static timeMap times;
    clock_t timeCalled;
    int myParm1;
    int myParm2;

public:
    TimeIt(int parm1, int parm2) : timeCalled(clock()), myParm1(parm1), myParm2(parm2) {}

    ~TimeIt() {
        clock_t runtime = clock() - timeCalled;
        if(timeMap::iterator it = times.find(std::pair<int,int>(myParm1,myParm2))) {
            it->second->first++;
            it->second->second+=runtime;
        }
        else {
            times[std::pair<int,int>(myParm1,myParm2)] = std::pair<int,int>(1,runtime);
        }
    }

    static void report() {
        for(timeMap::iterator it=times.begin();it!=times.end();it++) {
             cout << it->first->first << " | ";
             cout << it->first->second << " | ";
             cout << it->second->first << " | ";
             cout << (it->second->second/it->second->first) << endl;
        }
    }
}

Quindi nel tuo metodo, fai:

int myFunction(int myParam1, int myParam 2) {

    TimeIt timeIt;

    // Do and return something based on the value of myParam1 and myParam2. 
    // The code is likely to use if, for, while, switch, etc.... 
}

E quando vuoi i dati:

TimeIt::report();

Sono sicuro che puoi fare qualcosa di simile in .NET o Java. Il punto più importante è prendersi cura quando si prende il tempo () dell'orologio. Non vuoi fare nulla di significativo nel distruttore prima di afferrare l'orologio ().

Ovviamente se vuoi una soluzione più generale, vuoi un vero profiler.

Risposta solo per .NET

In base alle mie conoscenze, non è possibile recuperare il valore effettivo dei parametri passati a un metodo.

Certo, puoi ottenere una serie di oggetti ParameterInfo, attraverso i quali puoi conoscere molto sui parametri ... ma purtroppo non puoi accedere ai loro valori. Certo, ci sono alcuni modi per indagare sulla traccia dello stack, ma non è garantito che siano abbastanza robusti in tutte le condizioni.

Quindi, no, sembra che tale strumento non possa nemmeno essere sviluppato per .NET.

Tuttavia non conosco altre piattaforme.

Anche se un tale strumento potrebbe essere molto utile, non sono a conoscenza di alcunché offra un'analisi dell'hotspot basata su linea. Dato che i profiler sono difficili da hackerare e facilmente sbagliati, probabilmente sei sicuramente meglio dividere temporaneamente il tuo codice in diverse funzioni solo così un normale profiler può dirti quello che devi sapere.

Dubito che troverai questo strumento, quindi molto probabilmente dovrai implementare il tuo.

Tuttavia, ci sono profiler del codice (ad esempio callgrind al profilo c e c ++ del codice), che fornisce un valore che rappresenta un tempo relativo trascorso in una funzione.

Se vuoi profilare una sola funzione e conosci il piccolo numero di combinazioni di input che ti interessano, puoi aggiungere una sorta di "meccanismo di commutazione" che renderà le chiamate visibili in qualsiasi tipico profiler:

int myFunction_internal(int myParam1, int myParam 2) {
  // the main body
}

int myFunction_p1_p5() {
    return myFunction_internal(1,5);
}

int myFunction_p2_p5() {
    return myFunction_internal(2,5);
}

int myFunction_other(int myParam1, int myParam2) {
    return myFunction_internal(myParam1,myParam2);
}

int myFunction(int myParam1, int myParam2) {
   if(myParam1==1 && myParam2==5)
        return myFunction_p1_p5();
   if(myParam1==2 && myParam2==5)
        return myFunction_p2_p5();
   return myFunction_other(myParam1,myParam2);
}