Skip to content
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

Small runtime optimizations (variable lookup speeds) #11

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

josh-hernandez-exe
Copy link
Owner

Depending on the dice roll configuration many thousand (or even millions) of dice input will be processed.
Due to a design decision there really isn't any algorithmic optimization that can be made (and also maintain the flexibility of the program).

With that in mind, any function that is going to be ran in the time intensive loop in the program will have optimizations in the area of variable look up speeds.
The key optimization was to make any global or builtin lookup be a local lookup. In some cases a lookup in the function closure was the best that can be done since the function signature of the actual function to be ran wouldn't of supported extra keywords.

This is inspired by the python documentation at the end of the itertools library at the end of the recipes sections.
This idea is also talked about in a stackoverflow post which eludes to the fact that this is probably no longer as big as an issue as it used to be.

Another optimization implemented is to remove lambda functions in any part that would have been called in the time intensive loop. Though it seems the improvements are minor based of this. I also looked into this:

In [1]: a1=lambda: sum(range(10))

In [2]: def a2(): return sum(range(10))

In [3]: a3 = lambda sum=sum,range=range:sum(range(10))

In [4]: def a4(sum=sum,range=range): return sum(range(10))

In [5]: %timeit a1()
The slowest run took 9.81 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 432 ns per loop

In [6]: %timeit a2()
The slowest run took 4.11 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 431 ns per loop

In [7]: %timeit a3()
The slowest run took 4.12 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 412 ns per loop

In [8]: %timeit a4()
1000000 loops, best of 3: 418 ns per loop

Another runtime preformance article here.

most of these are making global variable lookups be local.
this will shed off some time since these functions can be called tens of thousands of times.

there are still some things that take a while.
if-else statments currently process all cases due to the implementation.
in order for this to change, a refactor in argument passing needs to be done.
lambda functions are slower in general.
also the runtime can be further speed up with the optimization strategy of speeding up variable lookup.
…lambdas

this is in line with many of the other optimizations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant