ytelsestest av funksjonene

stemmer
3

linux gcc 4.4.1 C99

Jeg lurer på hva som er den beste måten å teste ytelsen til et C-program.

Jeg har noen funksjoner som jeg har implementert. Men jeg kunne ha brukt en annen design for hver funksjon.

I utgangspunktet skulle jeg ønske å teste for å se hvilke design gir bedre ytelse.

Mange takk,

Publisert på 30/12/2009 klokken 00:38
kilden bruker
På andre språk...                            


6 svar

stemmer
4

Ta en titt på dette innlegget på kodeprofilerings.

Svarte 30/12/2009 kl. 00:44
kilden bruker

stemmer
1

Det første du må finne ut er om du trenger for å optimalisere disse funksjonene. Med mindre de er i kritisk vei for koden din, kan de være mer enn rask nok.

Hvis du har profilert søknaden din og funnet de er treg, er en god måte å teste ytelsen å kalle funksjonen noen store antall ganger, og for å finne ut den gjennomsnittlige tiden det tar å kjøre.

Du bør også prøve å bruke CPU-tid i stedet for wallclock-tid som det er et mer nøyaktig mål.

Svarte 30/12/2009 kl. 00:44
kilden bruker

stemmer
2

Det meste du ønsker å bruke et profiler. Innlegget påpekt av Fragsworth er en god start. Personlig foretrekker jeg Shark for Mac OS X, og gprof for Linux.

Men i ditt tilfelle, kan du også ringe klokke () eller getrusage (), for eksempel på denne måten:

clock_t t = clock();
for (i = 0; i < 1000; ++i) my_func();
printf("time = %lf\n", (double)(clock() - t) / CLOCKS_PER_SEC);

Profiler er nyttig når du ønsker å grave ut hvilken del av koden tar mest tid. Ringe klokke () / getrusage () er mer praktisk (for meg) når du vil sammenligne / benchmark ulike implementeringer.

Svarte 30/12/2009 kl. 02:00
kilden bruker

stemmer
3

Jeg ønsker å teste for å se hvilke design gir bedre ytelse.

Hvorfor gjør det noe? Dette er ikke en flip spørsmålet! Du bør ha et resultatmål i tankene, og hvis du møter det, er koden raskt nok.

Hvordan vet du hvor fort er "rask nok"? Det viser seg at brukergrensesnittet folk har gode data på effekten av responstid på brukernes erfaring:

  • 0,1 sekund er omtrent den grense for at brukeren føler at systemet reagerer momentant, hvilket betyr at ingen spesiell tilbakemelding er nødvendig, og å vise resultatet. (De fleste mennesker har en reaksjonstid på 0,1 sekunder, jet fighter piloter komme ned til rundt 0.08s, dvs. 80ms.)

  • 1 sekund er om grensen for brukerens strømmen tenkt å bo uforstyrret, selv om brukeren vil merke forsinkelsen. Normalt er ingen spesiell tilbakemeldinger nødvendig under forsinkelser på mer enn 0,1, men mindre enn 1,0 sekund, men brukeren mister følelsen av direkte "kjøring" søknaden din.

  • 10 sekunder er om grensen for å holde brukerens oppmerksomhet fokusert på app. For lengre forsinkelser, vil brukerne ønsker å utføre andre oppgaver mens du venter på datamaskinen for å fullføre, så de bør gis tilbakemeldinger som indikerer når datamaskinen forventer å bli ferdig. Tilbakemelding under forsinkelsen er spesielt viktig hvis responstiden er vanskelig å forutsi eller varierer mye.

De kvantitative resultatene ovenfor gjelder bare for interaksjon, selvfølgelig, som måles i sekunder av ventetid. Men selv om målet ditt er nettverkspakker sendes, sider med RAM tildelt, blokker med disk leses / skrives, eller bare watt strøm forbrukes, meldingen jeg prøver å formidle er at du bør ha et resultatmål , at målet bør være kvantifisert , og målet bør være koblet til behovene til brukerne . Hvis du ikke har en kvantifiserbare mål, er du ikke gjør engineering; du bare piping i mørket. Med mindre målet ditt er å utdanne deg selv (eller for å tilfredsstille tomgang nysgjerrighet), spørsmålet du bør spørre er "er min kode god nok til at jeg kan gå videre?"


Hvis du ikke oppfyller resultatmålet, eller hvis du prøver å utdanne deg selv, jeg tror den beste kombinasjonen av lesbar og detaljert informasjon kommer fra å bruke Valgrind profiler ( --tool=callgrind --dump-instr=yes) sammen med kcachegrindvisualiserer.

Svarte 30/12/2009 kl. 02:20
kilden bruker

stemmer
1

Du kan bruke gprof, som er en gratis profiler.

Svarte 30/12/2009 kl. 15:05
kilden bruker

stemmer
0

Jeg tillegg til profilering du trenger for å kjøre koden under test fra en sele (driver) til gjennomsnittlig ut målingene. På denne måten sammenligninger ikke er fordreid av en av målingene, så har du et stort utvalg befolkning med gjennomsnitt og standardavvik for å sammenligne. Det er mange flertrådede rammeverk som kan oppnå belastningen kjøring for deg.

Svarte 29/03/2013 kl. 12:53
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more