This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

Author christian.heimes
Recipients Arfrever, Giovanni.Bajo, PaulMcMillan, Vlado.Boza, alex, arigo, benjamin.peterson, camara, christian.heimes, dmalcolm, koniiiik, lemburg, serhiy.storchaka, vstinner
Date 2012-11-07.11:53:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1352289191.91.0.972472753019.issue14621@psf.upfronthosting.co.za>
In-reply-to
Content
Serhiy, the performance of hash() for long strings isn't very relevant for the general performance of a Python program. Short strings dominate. I've modified the timeit to create a new string object every time.

for I in 5 10 15 20 30 40 50 60; do echo -ne "$I\t"; ./python -m timeit -n100000 -r30 -s "h = hash; x = 'ä' * $I" -- "h(x + 'a')" | awk '{print $6}' ; done

ASCII:
#       SIP        FNV
5       0.112      0.0979
10      0.115      0.103
15      0.12       0.107
20      0.124      0.112
30      0.126      0.127
40      0.136      0.142
50      0.142      0.147
60      0.146      0.159

UCS-2:
#       SIP        FNV
5       0.114      0.0977
10      0.117      0.0988
15      0.12       0.11
20      0.126      0.109
30      0.13       0.122
40      0.14       0.132
50      0.144      0.147
60      0.152      0.157

For short strings the additional round and setup costs make hash() about 10% slower. For long strings SIP is faster as it processes 8 bytes at once instead of 1 to 4 bytes.
History
Date User Action Args
2012-11-07 11:53:11christian.heimessetrecipients: + christian.heimes, lemburg, arigo, vstinner, benjamin.peterson, Arfrever, alex, dmalcolm, Giovanni.Bajo, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, camara
2012-11-07 11:53:11christian.heimessetmessageid: <1352289191.91.0.972472753019.issue14621@psf.upfronthosting.co.za>
2012-11-07 11:53:11christian.heimeslinkissue14621 messages
2012-11-07 11:53:11christian.heimescreate