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

Try to reclaim performance #46

Closed
HighDiceRoller opened this issue May 24, 2022 · 5 comments
Closed

Try to reclaim performance #46

HighDiceRoller opened this issue May 24, 2022 · 5 comments

Comments

@HighDiceRoller
Copy link
Owner

While 0.13.0 has a simpler interface than pre 0.13 the performance is much worse on some cases. I need to figure out what's going on and try to reclaim some of that performance.

  • Caching?
  • More expensive object startup?
  • Core algorithm inefficiencies?
@HighDiceRoller
Copy link
Owner Author

The cached direction is quite a bit better; I've adjusted the algorithm selection code to favor it more. Still a factor of ~2x worse than pre 0.13.

@HighDiceRoller
Copy link
Owner Author

HighDiceRoller commented May 24, 2022

It looks like the dual-purpose == is hurting us here, checking logical die equality becomes a $n^2$ algorithm.

Options:

  • Figure out some lazy evaluation scheme.
  • Go back to only equals() for probabilistic equality.

@HighDiceRoller
Copy link
Owner Author

Lazy evaluation seems to work so far.

@HighDiceRoller
Copy link
Owner Author

Split off comparator handling to #48 .

@HighDiceRoller
Copy link
Owner Author

Seems good enough for now.

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

No branches or pull requests

1 participant