As per:
Re: [PATCH 2/2] Clean: Actually use HvUSEDKEYS() instead of HvKEYS()
Sun, 15 May 2011 20:29:05 +0000
Message-Id: <
2a28ed668b6641e6b5f6e0fb4e5374b4-mfwitten@gmail.com>
the text in question was introduced along with the test in this commit:
$ c=
58da6fbcb8d595318b667d7d7cc8739f5feb15f3
$ git log -1 $c
commit
58da6fbcb8d595318b667d7d7cc8739f5feb15f3
Author: Max Maischein <corion@corion.net>
Date: Mon Jun 1 14:18:42 2009 +0200
Add benchmark test for keys() on empty hashes (RT26188)
I believe the text in question is an allusion to the code introduced in
the parent commit:
$ git log -1 $c^
commit
900ac0519e4b408fd93443b14b734cc330c59698
Author: Max Maischein <corion@corion.net>
Date: Sun May 31 23:50:12 2009 +0200
Fix RT26188, speed up keys() on empty hash
namely the code starting at line 2132 of
900ac0519e4b408fd93443b14b734cc330c59698:hv.c:
/* At start of hash, entry is NULL. */
...
if (HvKEYS(hv) || (flags & HV_ITERNEXT_WANTPLACEHOLDERS)) {
...
}
...
return entry;
It is best just to remove the text in question, as it is of no
real use.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
about_as_fast_ok( $res, 'lex_big', 'big', "Checking the list of hash keys in an empty hash, global vs. lexical");
__END__
-
-# code written
- /* quick bailout if the hash is empty anyway.
- I don't know if placeholders are included in the KEYS count, so a defensive check
- */
- if (! HvUSEDKEYS(hv) && !(flags & HV_ITERNEXT_WANTPLACEHOLDERS) )
- return NULL;