-
Notifications
You must be signed in to change notification settings - Fork 6
Optimize sliding
#31
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
Optimize sliding
#31
Conversation
Time Complexity: from O(n² / step) to O(N) Space Complexity: from O(n / step) to O(N / step)
LGTM, only it would be better to keep the names of the arguments |
Done. This was practically copied from my project, which was using the Clojure signature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome 🙏 🔥
Thanks. I hope I hadn't introduced any non-obvious regressions. Hoping there's maybe still something to make this function faster. |
@walking-octopus 🤦 My bad. Your original message made me think that maybe you didn't check the unit tests... which of course are failing now. I am going to revert the changes. I was a bit too trusting on this one. I don't actively work in Racket these days so i am happy to accept any and all PRs. Will check that tests are passing next time. |
@walking-octopus, happy to accept changes in a new PR if they don't break the tests. |
Performance
* If my analysis is correct
Changes
length
may be quite fast, even on large inputs, but it's still O(N), making the total time complexity quadratic. I tested this change in my Markov chain implementation, and it made a meaningful performance difference on large corpora without any apparent regressions.While accumulating in reverse order may have lead to better space complexity due to TCO, the
reverse
in the base case or expensiveappend
negates any difference made in time, so the results are inconsistent; if order doesn't matter, it can cut the time in half. In my defense, the previous version didn't use TCO despite having a subprocedure calledtail-call
, because the self-call was wrapped in cons.I'm sure we can squeeze more performance still, but probably only a modest asymptotic or even constant factor difference and will make the logic less clear. Any input is welcome.