Keys are calculated by amalgamating the values of the chars in the key. Accordingly there will be a run time cost for using longer keys. However I should think that on modern PC's you will find that the keys would have to be very long before the difference was measureable. The actual C code used to calculate the key is in the following readmore:

#define PERL_HASH(hash,str,len) \
     STMT_START    { \
    register const char *s_PeRlHaSh_tmp = str; \
    register const unsigned char *s_PeRlHaSh = (const unsigned char *)
+s_PeRlHaSh_tmp; \
    register I32 i_PeRlHaSh = len; \
    register U32 hash_PeRlHaSh = PERL_HASH_SEED; \
    while (i_PeRlHaSh--) { \
        hash_PeRlHaSh += *s_PeRlHaSh++; \
        hash_PeRlHaSh += (hash_PeRlHaSh << 10); \
        hash_PeRlHaSh ^= (hash_PeRlHaSh >> 6); \
    } \
    hash_PeRlHaSh += (hash_PeRlHaSh << 3); \
    hash_PeRlHaSh ^= (hash_PeRlHaSh >> 11); \
    (hash) = (hash_PeRlHaSh + (hash_PeRlHaSh << 15)); \
    } STMT_END
[download]

For the example you posted 'placedtiles' versus 'pt' i should think the difference would be negligable for most applications. Also as another poster stated you'll see no difference at runtime with using longer var names and shorter ones. Its very unlikely that you will notice a startup cost for longer vars, but it is possible mostly for IO reasons I should think. OTOH you'll almost certainly notice maintainance issues with the short names. IMO the cost/benefit breakdown will in almost all circumstances be in favour of using longer more descriptive names for both hash keys and var names. If you really need it to be faster then switch to using arrays or switch to using C.

BTW, i think this is an appropriate time to bring up the old adage: "Premature optimisation is bad." Get the code working then profile it to identify optimisation targets if you really need it to be faster.