Quando i micro-benchmark hanno senso? [chiuso]

1

Ho svolto ricerche su micro-benchmark (ad esempio utilizzando JMH o Caliper , sebbene non necessariamente limitato a Java). Ora, ci sono molti articoli che descrivono come scrivere un benchmark ma non ho trovato molto su quando per scrivere un benchmark (e quando non farlo). C'erano alcune cose che vanno in quella direzione, per esempio

Continuous delivery, continuous testing… is one thing, but continuous measuring is another step.

o

Always Measure

Before you start optimizing, make sure you have a problem that you need to solve. Make sure you can accurately measure your existing performance, or you won't be able to measure the benefit of the alternatives you try.

Ma per me è solo un valore limitato.

Quindi la mia domanda è: in quali scenari hanno senso i micro-benchmark? Quando no? Per cosa dovrebbero e non dovrebbero essere usati? E qualcuno qui ha esperienza di vita reale con micro-benchmarking in un grande progetto?

    
posta blalasaadri 24.06.2015 - 21:41
fonte

1 risposta

4

I micro-benchmark possono essere utilizzati in aggiunta a un profiler per trovare e correggere parti problematiche del codice. Quindi, puoi eseguire un profiler per identificare le regioni problematiche e quindi testare quelle regioni specifiche con micro-benchmark.

In generale, i framework di micro-benchmark (come Caliper e JMH) sono progettati per prevenire molti degli errori più comuni e semplificare la creazione di benchmark significativi (come descritto nella risposta a questa domanda ). Questi sono in molti casi problemi che non si verificano nella stessa forma quando stai testando pezzi di codice più grandi; quindi ha senso mantenere piccoli i benchmark micro. (Questo è il motivo per cui sono chiamati micro -benchmarks dopo tutto.)

Alcune cose che ho trovato sono le seguenti.

Misura:

  • se hai trovato un collo di bottiglia e potresti avere una soluzione migliore
  • se stai confrontando diverse tecnologie che possono svolgere lo stesso lavoro (ad es. parser xml) e vuoi sapere qual è il più veloce prima di utilizzarle nel tuo codice reale
  • se non hai nient'altro da migliorare sul tuo codice

Non misurare:

  • se il codice ha dipendenze esterne non attendibili dal punto di vista del tempo (ad es. parla su una rete)
  • se la parte di codice misurata non verrà chiamata molto spesso (o se non si è sicuri) a meno che la propria applicazione non sia REALMENTE sensibile al fattore tempo. (= Se esegui raramente un pezzo di codice, non provare a ottimizzarlo, probabilmente non ne valuterà il tempo. )
  • se l'operazione richiederà più di qualche millisecondo per completare
  • solo perché il tuo capo, manager o qualcun altro che è responsabile pensa che sia una buona idea farlo

Inoltre, mentre alcune persone eseguono regolarmente micro-benchmark (come fareste con i test unitari), dal momento che li uso solo per analizzare problemi che conosco già (grazie al profiler), questi benchmark non sono qualcosa di cui ho bisogno correre molto spesso. Potrebbero esserci situazioni in cui ciò avrebbe senso (e se ne conoscete uno, per favore commentate!) Ma probabilmente sarebbe un modo totalmente diverso di usare tali strumenti.

    
risposta data 25.06.2015 - 17:26
fonte

Leggi altre domande sui tag