Registrazione basata su eventi. È una buona idea ed è giusto passare un handle ad un oggetto "loggato"?

2

Ciao ho un programma abbastanza complesso che sta facendo calcoli in un ciclo abbastanza grande. Voglio registrare alcune statistiche di base sulla corsa per essere in grado di analizzare le sue prestazioni nel tempo e il numero di loop. Per ora sto emettendo un insieme di numeri, circa 5 o 6, ogni ciclo.

Il problema è che il numero di cicli è abbastanza grande, quindi i file di registro sono grandi. Anche mettere 10 ^ 6 punti di misurazione su una trama è un po 'inutile.

Ho pensato di "filtrare" i risultati, ad esempio stampando ogni 1kthth loop ma perderei alcuni punti di interesse. Inoltre, non riesco a registrare solo POI, perché perderei la traccia dei progressi generali.

Ho deciso di passare a una registrazione basata su eventi. In primo luogo, gli eventi che ho in mente sono la combinazione delle due cose summenzionate: miglioramento della soluzione corrente e alcuni progressi sui loop.

L'implementazione che ho in mente è scrivere un semplice StatLogger che sarebbe responsabile per l'output dei dati nel flusso di log. Il programma principale emetterebbe appena un metodo log() ogni volta che si verifica un evento. Gli eventi possono verificarsi simultaneamente e non ha senso registrare lo stato due volte, quindi la classe sarebbe responsabile di non emettere due volte le statistiche.

Le mie domande sono:

  1. È un approccio o modello valido o comune?
  2. È meglio passare un gestore all'oggetto numero cruncher, in modo che il logger possa ottenere tutte le statistiche interessanti come StatLogger::log(const RunEnviroment *this) , oppure è meglio creare un'altra struttura per contenere tutte le statistiche interessanti e creare un metodo StatLogger::log(const Stats& stats) .
  3. Se il mio approccio è sbagliato, quali sono le soluzioni più comuni in casi simili?
posta luk32 15.07.2013 - 17:35
fonte

2 risposte

1

Eviterei qualcosa di generale come StatLogger per dipendere da qualcosa di speciale come RunEnviroment , qualunque sia l'aspetto. Mantenere StatLogger indipendente probabilmente migliorerà la testabilità e la riusabilità di quella classe.

Se è necessario, tuttavia, un metodo semplice come

  StatLogger::log( EnumEventType evenTtype, const std::string &logtext) 

o qualcosa di simile

  StatLogger::log(const Stats& stats) 

(dove suppongo che Stats rappresenti una voce di registro ), dipenderà principalmente dalle informazioni che verranno registrate e dalla complessità di tali informazioni.

Se vuoi disaccoppiare il tuo programma principale da un logger specifico, puoi anche introdurre una classe base astratta come un'interfaccia (come IStatLogger ), e lasciare che il tuo programma principale acceda al logger solo attraverso quell'interfaccia. Ciò ti consentirà di sostituire facilmente il logger reale con un logger finto a scopo di test.

    
risposta data 16.07.2013 - 14:31
fonte
0

Una soluzione potrebbe essere quella di introdurre i livelli di registrazione. Ogni livello corrisponderebbe all'importanza (o forse alla priorità) delle informazioni del registro. Tale strategia consentirebbe di raggruppare le informazioni del registro e quindi di filtrarle più facilmente. Questi gruppi potrebbero essere ad esempio:

  • TRACE; DEBUG; INFORMAZIONI; AVVISARE; ERRORE; FATAL

Una tale implementazione può essere trovata nel kernel di Linux.

Inoltre, sono sicuro che troverai ulteriori informazioni cercando su Google varie implementazioni di logger.

    
risposta data 16.07.2013 - 20:56
fonte

Leggi altre domande sui tag