HeVAL(entry) returns the "SV *" pointer that refers to the scalar value in the hash entry.

In order to create a Perl-style "scalar reference" to the scalar value, hv_exists_ent() would need to return:

newRV_inc(HeVAL(he))

The result of this invocation would be a new RV (Perl-style "scalar reference"). The reference count for the hash entry value would be incremented.

From the Perl side of things, a scalar needs to be allocated to hold the reference, the reference then needs to be assigned to a scalar to hold it, before checking it for "truthfulness". Then, later, in order to fetch the value, or store a new value into the hash value, the reference needs to be dereferenced. For example:

my $reference_to_value;
if ($reference_to_value = exists $hash{$key}) {
    print "value is $$reference_to_value\n";
}
[download]

The question is, would all this additional overhead actually be any benefit over the common case:

if (exists $hash{$key}) {
    print "value is $hash{$key}\n";
}
[download]

A further consideration is the overhead in the case where the return value is only interpretted as a boolean value, and not later used to dereference to access the hash entry value: Since a reference was created, but not used except as a 'truth' value, it then needs to be destroyed.

So, as you can see, returning more information, while useful under circumstances where the information is effectively used, can reduce the performance of the case where the information is not actually used. Intuitively, this should be expected, although sometimes it needs to be presented in this light to make the situation visible. :-)

Hash lookups are very fast. I believe that the 'exists() returns a reference' solution is not optimal overall.

Far better avenues to consider would include caching the string hash value, or enhancing the optimizer to detect the situation where the exists is followed by a lookup, and the key has not changed, and to instead generate new op-codes for the exist() that would store the value away in the pad somewhere, and the lookup that would fetch the value from the pad. The benefit of the latter model would be that code such as the following could be optimized:

$hash{$key}{'a'} = 'A';
$hash{$key}{'b'} = 'B';
$hash{$key}{'c'} = 'C';
[download]

The optimizer could detect that the value ($key) was not altered between use, and the same hash entry value could be reused each time.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.