develooper Front page | perl.perl5.porters | Postings from November 2003

hv.c went on a diet

Thread Next
From:
Nicholas Clark
Date:
November 22, 2003 11:46
Subject:
hv.c went on a diet
Message ID:
20031122194530.GK11153@plum.flirble.org
I think I've finished hacking hv.c (in blead)
It's now 15% smaller, hv.o is about 10% smaller, and perl about 0.4% smaller.

hv_delete and hv_delete_ent now act as wrappers onto a single static
function hv_delete_common

hv_exists, hv_exists_ent, hv_fetch, hv_fetch_ent, hv_store, hv_store_ent
and hv_store_flags all act as wrappers onto a single static function
hv_fetch_common.

Most of the non-magic code was duplicated between the 6 functions doing
fetch, store and exists. Moreover, the call path for an LVALUE fetch
(what perl's ops use to create hash entries) involved checking that the
key was present in the hash buckets, and if it was not, making a call
into hv_store. Which did the check on the buckets all over again.

That double check has been eliminated. Sadly I can't detect a speedup as
a result. I was hoping that it would help.

It should be 100% binary compatible - I've only changed static functions
in hv.c, and taken care to ensure that the calls to magic still happen
in the old order. However, it's not merged to maint yet.

Rather than appending the overlapping patches here, I suggest that anyone
who is interested look at the patches involving recent changes to hv.c:

http://public.activestate.com/cgi-bin/perlbrowse?file=hv.c&log=1

starting with change 21734, which fixes an existing utf8 bug

http://public.activestate.com/cgi-bin/perlbrowse?patch=21734


A side effect of this is that I've written ext/XS/APItest/t/hash.t,
which systematically tests the hash API with combinations of utf8 and
non-utf8 data.

Nicholas Clark

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About