%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
In reply to Re: undef speedup ?!
by blokhead
in thread undef speedup ?!
by powerman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |