Message385996
Based on Hristo's timing, it appears to be a clear win.
A near-wash for truly string-only dicts that shouldn't be effected; a near-wash for looking up non-(exact-)strings, and a nearly 40% speedup for the target case of looking up but not inserting a non-string or string subclass, then looking up strings thereafter.
Additional comments:
Barring objections, I will promote from patch review to commit review when I've had a chance to look more closely. I don't have commit privs, but I think some of the others following this issue do.
The test looks pretty good enough -- good enough that I wonder if I'm missing something on the parts that seem odd. It would be great if you either cleaned them up or commented to explain why:
Why is the first key vx1, which seems, if anything, like a variable?
Why not k1 or string_key?
Why is the first key built up as vx='x'; vx += '1' instead of just k1="x1"?
Using a str subclass in the test is a great idea, and you've created a truly minimal one. It would probably be good to *also* test with a non-string, like 3 or 42.0. I can't imagine this affecting things (unless you missed an eager lookdict demotion somewhere), but it would be good to have that path documented against regression.
This seems like a test that could probably be rolled into a bigger testfile for the actual commit. I don't have the name of such an appropriate file at hand right now, but will try to find it on a deeper review. |
|
Date |
User |
Action |
Args |
2021-01-30 20:59:25 | Jim.Jewett | set | recipients:
+ Jim.Jewett, benjamin.peterson, Mark.Shannon, serhiy.storchaka, h.venev, vaultah |
2021-01-30 20:59:25 | Jim.Jewett | set | messageid: <1612040365.74.0.927859111752.issue24275@roundup.psfhosted.org> |
2021-01-30 20:59:25 | Jim.Jewett | link | issue24275 messages |
2021-01-30 20:59:25 | Jim.Jewett | create | |
|