-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Save OrderedDict import in re #76519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Since regular dicts are now ordered by default, the OrderedDict import is no longer necessary. |
Please don't do this. |
This is surprising. But OrderedDict also can be O(N) here. Do you have benchmarking results Inada? |
Current dict implementation doesn't skip empty entries. (I fixed it in compact ODict branch, but it added one word to dict)
$ ./python -m perf timeit -s 'cache={}' -- '
for i in range(10000):
if len(cache) > 512:
del cache[next(iter(cache))]
cache[i]=i
'
.....................
Mean +- std dev: 6.81 ms +- 0.08 ms
$ ./python -m perf timeit -s 'from collections import OrderedDict; cache=OrderedDict()' -- '
for i in range(10000):
if len(cache) > 512:
cache.popitem(last=False)
cache[i]=i
'
.....................
Mean +- std dev: 3.75 ms +- 0.07 ms Performance difference is measurable even when N is only 512. Maybe, we can use hack similar to Python 3.5 had for O(1) popitem(). |
Hmm, 0.3 μs for each lookup may be negligible compared to re.compile() speed? |
We are talking about a dictionary of 512 items in the worst case. On such very tiny collection, benchmarking matters more than O(...) complexity ;-) |
You're right. Rob Pike said: "Fancy algorithms are slow when n is small, and n is usually small." |
OK, performance difference is negligible, surely. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: