-
Notifications
You must be signed in to change notification settings - Fork 46
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
Consider moving Streams to use simpler, single-threaded Cancellation token #32
Comments
dsyme
changed the title
Consider moving Streams from Cancellation token to register
Consider moving Streams to use simpler, single-threaded Cancellation token
Jun 11, 2015
Actually I was aware of the multithreaded nature of CancellationTokenSource (I'm using it in ParStream) but I thought that is was lightweight enough and that I pay the allocation cost only for early termination combinators like (take, find etc) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As far as I can tell stream iteration is inherently single threaded in the sense that, like Seq, the Iterable and Iterator objects are accessed linearly.
In this setting, the use of CancellationTokenSource has costs because accesses are multi-threaded ready and are ultimately synchronized via a Volatile field. So I experimented with changing to use simpler, single-threaded Stream cancellation tokens. The branch and diff is here: dsyme/Streams@hide-reprs...dsyme:no-cts-for-streams (this builds on #31 and #30). In some cases the code seems to be simpler in any case (since we effectively switch between Boolean flags and cancellation tokens in any case) unless there's something I've missed.
Note that no disposal is needed on these since they don't have wait handles
Raw iteration performance seems to be improved by around 5-10%:based on the runStream() sample in Streams.fs
If you think this is a good idea I can submit a PR.
AFTER:
before:
The text was updated successfully, but these errors were encountered: