vr has asked for the wisdom of the Perl Monks concerning the following question:
Just curious, not a 'problem' which requires solution. Maybe developers thought real numbers stringification is usually approximate, that's why? Or simply nobody cares?
C:\>perl -MDevel::Peek -e "$x = 0.5; qq/$x/; Dump $x" SV = PVNV(0x38bb4) at 0xd217cc REFCNT = 1 FLAGS = (NOK,pNOK) IV = 0 NV = 0.5 PV = 0xd16014 "0.5"\0 CUR = 3 LEN = 28 C:\>perl -MDevel::Peek -e "$x = 0; qq/$x/; Dump $x" SV = PVIV(0xd200c4) at 0xd2685c REFCNT = 1 FLAGS = (IOK,POK,pIOK,pPOK) IV = 0 PV = 0xd16274 "0"\0 CUR = 1 LEN = 10
Hence, 'double' is converted to string any time it is required. E.g.:
use Benchmark qw/ cmpthese /; $x = 42.0; %h = (); cmpthese( -1, { F => sub { $h{ pack 'F', $x } = 1 }, s => sub { $h{ $x } = 1 }, });
Rate s F s 344025/s -- -86% F 2490475/s 624% --
I found that one my little application, which maintains kind of 'seen' hash, gets nice boost if hash keys are packed as above, instead of 'just used as they are'. Actually, keys are pixels coordinates, they became real numbers because library I use returns them so. Pixels are usually aplenty and hash is accessed a lot, therefore speed gain was significant. But of course it would be even faster if PV was added on first access and POK was set, i.e. without packing.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Any reason NV is not marked as POK when accessed as string?
by dave_the_m (Monsignor) on Mar 23, 2017 at 11:56 UTC | |
by demerphq (Chancellor) on Mar 23, 2017 at 19:12 UTC | |
by syphilis (Archbishop) on Mar 23, 2017 at 23:16 UTC | |
by demerphq (Chancellor) on Mar 23, 2017 at 23:23 UTC | |
by vr (Curate) on Mar 23, 2017 at 13:03 UTC | |
Re: Any reason NV is not marked as POK when accessed as string? (updated)
by haukex (Archbishop) on Mar 23, 2017 at 12:11 UTC | |
by vr (Curate) on Mar 23, 2017 at 13:14 UTC |