in reply to undef speedup ?!
%h_delete = %h_list = %h_undef = (0 .. 50000); delete @h_delete{keys %h_delete}; %h_list = (); undef %h_undef; use Devel::Peek; Dump \%h_delete; Dump \%h_list; Dump \%h_undef;
Output:
SV = RV(0x830eb38) at 0x838d3a4 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x8171818 SV = PVHV(0x8171d20) at 0x8171818 REFCNT = 2 FLAGS = (SHAREKEYS) IV = 0 NV = 0 ARRAY = 0x40376008 KEYS = 0 FILL = 0 MAX = 32767 RITER = -1 EITER = 0x0 SV = RV(0x830eb38) at 0x838d3a4 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x81765cc SV = PVHV(0x8171d50) at 0x81765cc REFCNT = 2 FLAGS = (SHAREKEYS) IV = 0 NV = 0 ARRAY = 0x403d8008 KEYS = 0 FILL = 0 MAX = 32767 RITER = -1 EITER = 0x0 SV = RV(0x830eb38) at 0x838d3a4 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x81765fc SV = PVHV(0x8171d80) at 0x81765fc REFCNT = 2 FLAGS = (SHAREKEYS) IV = 0 NV = 0 ARRAY = 0x0 KEYS = 0 FILL = 0 MAX = 7 RITER = -1 EITER = 0x0
All the hashes have KEYS = 0, and you would think Perl would be smart enough to notice this when you call keys. The only difference in the 3rd one (%h_undef) is that it has no ARRAY pointer (with MAX set accordingly). I would guess that keys travels that entire array looking for keys, and that's where the slowdown is. This seems to be the case from looking at Perl_hv_iternext_flags. A definitive explanation from someone more versed in the internals is welcome ;)
I don't see why the KEYS = 0 case couldn't be optimized; perhaps you should file a bug and see!
blokhead
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: undef speedup ?!
by gmpassos (Priest) on Feb 08, 2004 at 21:31 UTC | |
|
Re: Re: undef speedup ?!
by powerman (Friar) on Feb 08, 2004 at 21:56 UTC |