Thorbjørn Ravn Andersen <thunderbear@bigfoot.com> skrev i
meldingsnyheter:3AE490E8.9D52DADE@bigfoot.com...
> "Stig H. Jacobsen" wrote:
>> Jeg hopper af tråden.
> Det er da ellers netop først når der bliver _målt_ at det giver mening
> at snakke om optimering. Hop på igen - Benchmark er et fantastisk
*host* Dessverre er det slik at det er lett å glemme seg bort, og benchmarke
noe som optimizes bort av kompileren :( *blush*
Ny benchmark følger...
#!/usr/bin/perl
use Benchmark;
my $num = 2.34567;
timethese (1_000_000, {
var_int => q{my $i = int($num * 10)/10},
var_sprintf => q{my $i = sprintf "%.1f", $num},
const_int => q{my $i = int(2.34567 * 10)/10},
const_sprintf => q{my $i = sprintf "%.1f", 2.34567},
});
__END__
Benchmark: timing 1000000 iterations of const_int, const_sprintf, var_int,
var_sprintf...
const_int: 1 wallclock secs ( 1.18 usr + 0.00 sys = 1.18 CPU)
const_sprintf: 1 wallclock secs ( 1.35 usr + 0.00 sys = 1.35 CPU)
var_int: 4 wallclock secs ( 3.59 usr + 0.00 sys = 3.59 CPU)
var_sprintf: 23 wallclock secs (23.01 usr + 0.00 sys = 23.01 CPU)
Stig har derfor helt rett i at sprintf() er tregere enn hans metode - nesten
seks ganger tregere, faktisk.
Men - det utgjør allikevel ikke mer enn 0,00002 sekunder pr. avrunding, og
med mindre du utfører fryktelig mange avrundinger i et program, så er
performance et ugyldig argument for å unngå sprintf().
Det viktigste bør være at koden gir riktig resultat, deretter er det viktig
at koden er lett å lese.
> værktøj (kombineret med Perl profilering som kun virker under Unix) til
> at blive klogere af.
Nettopp. Det er bl.a. annet det som menes med at "_premature_
micro-optimixing is the root of all evil". Man skal *ALDRI* foreta
mikro-optimalisering av kode før man er *HELT* sikker på at man kan oppnå
noe med det. En profilering vil avsløre hvilke subrutiner som kalles oftest,
og hvilke subrutiner som bruker mest CPU-tid i løpet av programmets levetid.
Det er bortkastet tid å optimalisere en subrutine så den blir dobbelt så
rask, dersom dette bare kutter eksekveringstiden til programmet med et
tiendels sekund. Spesielt dersom du kan kutte eksekveringstiden med 5
sekunder på å gjøre en annen subrutine 10% raskere.
> Herudover er det den eneste måde til at afgøre hvem der har ret, når man
> først er gået i skyttegravene.
( bare man er enige om at benchmarken er riktig utført
--
Trond Michelsen