Dove inserisci il tuo codice di profilazione?

0

Ho appena sviluppato un algoritmo e, oltre ai soliti test unitari, ho scritto un "test" di profilo che stavo usando per misurare e ottimizzare le sue prestazioni. È strutturato in modo simile a un test (organizzare: impostare una grande quantità di dati per elaborare, agire: eseguire l'algoritmo) ma senza lo stadio di asserzione (non prova nulla).

Ora che l'algoritmo è sufficientemente ottimizzato mi piacerebbe mantenere il codice di profilazione per riferimento futuro, ma dato che impiegano diversi secondi per essere eseguito senza testare realmente qualcosa, non voglio che venga eseguito ogni volta che eseguo i miei test unitari.

Ovviamente potrei trasformarlo in un test affermando che il tempo di esecuzione è inferiore a una certa soglia ma che sembra artificiale.

  • Devo trasformarlo in un test appropriato affermando un certo tempo di esecuzione?
  • Dovrei controllarlo così com'è?
  • Dovrei controllarlo come è ma disabilitarlo in modo che non funzioni automaticamente?
  • Dovrebbe essere in un file / assieme separato o insieme ai test delle unità?
  • Dovrei fare qualcos'altro?

Spero che esistano alcune best practice, quindi questo non sarà basato sull'opinione pubblica.

    
posta Roman Reiner 04.02.2016 - 10:45
fonte

1 risposta

2

SQLite separa i file di test come segue:

The "typical" workload is generated by the speedtest1.c program in the canonical SQLite source tree. This program strives to exercise the SQLite library in a way that is typical of real-world applications. Of course, every application is different, and so no test program can exactly mirror the behavior of all applications.

The speedtest1.c program is updated from time to time as the SQLite developers' understanding of what constitutes "typical" usage evolves.

The speed-check.sh shell script, also in the canonical source tree, is used to run the speedtest1.c program. To replicate the performance measurements, collect the following files into a single directory:

the "speed-check.sh" script, the "speedtest1.c" test program, and the SQLite amalgamation source files "sqlite3.c" and "sqlite3.h" Then run "sh speed-check.sh trunk".

Cachegrind is used to measure performance because it gives answers that are repeatable to 7 or more significant digits. In comparison, actual (wall-clock) run times are scarcely repeatable beyond one significant digit.

Il browser Firefox separa i test delle prestazioni dai test delle unità e esegue automaticamente i test delle prestazioni:

Every build of Firefox has Telemetry enabled. Local developer builds with no custom build flags will record all Telemetry data, but not send it out.

e include le seguenti funzionalità:

The about:telemetry page allows to view any data you submitted to Telemetry in the last 60 days, whether it is in existing pings or in new custom pings. You can choose which pings to display on the top-left.

You can find all important Telemetry resources listed on telemetry.mozilla.org.

Riferimenti

risposta data 27.04.2018 - 01:54
fonte