New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
caching overloading tables as magic slows down hash lookups #12404
Comments
From @nwc10The CV pointers for overloading methods are cached in a structure stored in It's been like this for approximately forever. (I believe) The result is that as soon as an object is destroyed, any lookups on that if (SvSMAGICAL(hv) && SvGMAGICAL(hv) && !(action & HV_DISABLE_UVAR_XKEY)) { That isn't great. I suspect that a solution is to move struct am_table from MAGIC into a Here's the long version. Looking up 'a' in %:: twice, before and after an Notice how first time through the code goes straight from line 404 to $ gdb --args ./perl -le '$::{a}; bless []; $::{a};' (gdb) b perl_run Breakpoint 1, perl_run (my_perl=0x100600080) at perl.c:2289 Breakpoint 2, Perl_hv_common (hv=0x100801f20, keysv=0x100810410, key=0x0, klen=0, flags=0, action=0, val=0x0, hash=3392050242) at hv.c:349 Breakpoint 2, Perl_hv_common (hv=0x10080fb88, keysv=0x10080fb58, key=0x0, klen=0, flags=0, action=4, val=0x1004c3448, hash=0) at hv.c:349 Breakpoint 2, Perl_hv_common (hv=0x100801f20, keysv=0x100810428, key=0x0, klen=0, flags=0, action=0, val=0x0, hash=3392050242) at hv.c:349 Nicholas Clark |
From @nwc10On Wed, Sep 12, 2012 at 08:54:15AM -0700, Nicholas Clark wrote:
Oh, addendum that I think I realised a couple of years ago but never got I think if DESTROY is cached, an entire array of CV pointers is allocated. Nicholas Clark |
From @cpansproutOn Wed Sep 12 08:54:15 2012, nicholas wrote:
perl-5.6.0-2080-g32251b2 commit 32251b2 speeding up object creation/destruction 4x times -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Wed Sep 12 08:54:15 2012, nicholas wrote:
Stashes are rarely blessed. Couldn’t we put it in SvSTASH instead? That would avoid making all iterated hashes bigger. It should also make -- Father Chrysostomos |
From @cpansproutOn Thu Nov 15 21:48:43 2012, sprout wrote:
And it worked. See commit 8c34e50. -- Father Chrysostomos |
@cpansprout - Status changed from 'open' to 'resolved' |
From @cpansproutOn Sat Nov 17 10:14:45 2012, sprout wrote:
Except I made the mistake of slowing down destruction of objects whose -- Father Chrysostomos |
@doy - Status changed from 'resolved' to 'open' |
From [Unknown Contact. See original ticket]Commit 8c34e50 breaks the attached script. I'm not sure if it's magical -- |
From @cpansproutOn Wed Aug 14 16:42:59 2013, doy wrote:
$\="\n"; Mea culpa. No generation number is associated with the DESTROY cache sneaked into -- Father Chrysostomos |
From @cpansproutOn Wed Aug 14 22:51:32 2013, sprout wrote:
This is fixed in c716b3b, which I would like to nominate for 5.18.2. -- Father Chrysostomos |
@rjbs - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#114864 (status was 'resolved')
Searchable as RT114864$
The text was updated successfully, but these errors were encountered: