Replies: 2 comments
-
It isn't exceptional for It may well be the case that when I refactor |
Beta Was this translation helpful? Give feedback.
-
Thanks @louthy! Even with the short monadic chain (and my first ever) that I am using as an exercise (obtaining an OAuth2 access_token given the authority Url) from 4 steps, just 2 of them are truly async. Furthermore, some naïve benchmarking could not detect a significant difference in memory allocation between Task and ValueTask in fully asynchronous calls (but the payload was small). On the other hand, all the documentation about ValueTask clearly recommend its use only when there is the possibility of a synchronous hot path. In that light the generalized use of ValueTask is a surprise; or was for me. The alternative would be to use Task and Task.FromResult... (basically going back to TryAsync?). Then I think I understand the situation better now. |
Beta Was this translation helpful? Give feedback.
-
In the Side Effects wiki document it says "[the asynchronous types] use ValueTask, which again is a struct and is much more optimal than Task", but, at least by my current understanding, ValueTask is optimal only when there is a hot synchronous execution path (like getting a cached value) and that seems exceptional to me. In the rest, more common, cases ValueTask, instead of being more optimal, implies some (small) overhead because of the larger size of the struct. What I am missing?
Thanks (specially for the documentation related to Side Effects)!
PS: I realize that ValueTask benefits the lifting of Pure functions (Capitalise) but it does not benefit the ones creating the effect (ReadAllLineAsync, ...) that are the raison d'etre of the whole thing. Then, still missing something.
Beta Was this translation helpful? Give feedback.
All reactions