Running into a similar deal, so I figured I'd share what I learned here.

First, you can't ever insert into a hash with only the hash value - you need the original string so that the hash implementation can do the final official comparison.

Next, while needing a SV is annoying, it's also related to performance. Perl has an internal pool of constants, and can make SVs from them. If your hash is using those as keys, and you perform the lookup using one, then the hash can skip the strncmp() and just compare the pointers. This is a lot like Java's String.intern(). I would presume that any time you use a literal key in your perl code, Perl probably adds that to the global pool and then hash get/set using those compiled scalars gets a lot faster. You can allocate one of these scalars with newSVpvn_share, if it is appropriate to do so. (obviously it would be bad to pollute the global string table with keys that come from transient data)

This doesn't solve the problem of wanting to have a more optimized way of fetching/storing a char* with a known hash, though. Looks like it's possible with the underlying implementation, but I haven't found any official API for it.

----- UPDATE -----

Looks like the authors of Class::XSAccessor had the same desire, so they just wrote new wrappers around hv_common_key_len. Of course it's probably a bad idea to reach that deep into perl for casual downstream modules, but the interesting bits can be found at: https://metacpan.org/source/SMUELLER/Class-XSAccessor-1.19/XS/Hash.xs