[HN Gopher] Async Rust in Practice: Performance, Pitfalls, Profi...
___________________________________________________________________
Async Rust in Practice: Performance, Pitfalls, Profiling
Author : uberdru
Score : 113 points
Date : 2022-01-12 18:45 UTC (4 hours ago)
(HTM) web link (www.scylladb.com)
(TXT) w3m dump (www.scylladb.com)
| throwaway81523 wrote:
| I haven't even clicked the link yet, but that the Scylla devs are
| doing something with Rust already is interesting. Seastar is very
| cool though constrained by the limitations of C++. It will be
| great to find out what effect Rust has.
| carllerche wrote:
| Tokio author here. Generally speaking, I recommend strongly
| against using FuturesUnordered unless you know all the pitfalls.
| We are working on an alternative utility that should hopefully
| avoid the issues described here and others:
| https://github.com/tokio-rs/tokio/pull/4335
| psarna wrote:
| That's great news! Especially that the observed performance of
| the test program based on FuturesUnordered, even though it
| stopped being quadratic, it was still considerably slower than
| the task::unconstrained one, which suggests there's room for
| improvement. Probably due to the fact that you still pay with a
| constant number of polls (32) each time you go out of budget.
| carllerche wrote:
| IMO FuturesUnordered should stop executing futures when it
| sees a "yield". An explicit yield signals control should be
| returned to the runtime. FuturesUnordered does not respect
| this.
| dagmx wrote:
| I'd love to read this article but man this site is painful on
| mobile. Multiple popups from the top, header that overlays the
| text, the chat bubble at the bottom.
|
| It really reduces the amount of space for the actual content
|
| When comparing to Reader View in Safari, the native site has at
| least 40% less viewing area
| dijit wrote:
| Seems alright on my iPad. https://imgur.com/a/SJwg1E2
| r00fus wrote:
| TBH, I've moved to setting Reader View as default for all
| Safari visits in iOS. You can whitelist sites or just undo
| reader view for that session if needed.
|
| Zero ads, and mostly I'm there for the text anyway.
| PeterCorless wrote:
| Hi Dagmx! Peter Corless here from ScyllaDB. Sorry to hear about
| your mobile experience. I've notified our web team. If you want
| to screenshot your mobile view to share with me, please email
| me at peter @ scylladb [dot] com. You have my commitment we'll
| be working on improving the page.
|
| Aside from that though, hope you were able to glean something
| valuable from the article. Would love to hear your opinions.
| dmitriid wrote:
| > If you want to screenshot your mobile view to share with me
|
| Just, you know, visit your own site on mobile.
|
| Or open Chrome dev tools and switch to mobile view.
|
| > You have my commitment we'll be working on improving the
| page.
|
| As with all in-your-face marketing shenanigans, I doubt
| you'll change anything in the long run.
| dmitriid wrote:
| Three screenshots: https://imgur.com/a/XUpP9ha
|
| Including the cookie banner that's illegal under GDPR (and is
| likely illegal under CCPA)
| throwaway81523 wrote:
| Xkcd 624?
| DenseComet wrote:
| I've been using Scylla for a project and have ended up
| reading quite a few of those blog posts. They are generally
| very well written and useful, but I've noticed the same sort
| of issues. There's the chat popup at the bottom, a banner for
| Scylla Summit, a cookie banner that doesn't seem to remember
| what I clicked, and a header with broken transparency.
|
| For me, Cloudflare is the benchmark. Cloudflare.com is very
| clearly a marketing site, likely run by their marketing team,
| but their technical content such as their blog and docs are
| on completely different subdomains with a clean design with
| no popups or banners. I think this is the best way to run
| tech focused blog, making both developers and marketing
| happy.
| psarna wrote:
| Hi, author of the post here. I'll also be talking about this
| issue in a little more detail at an online Rust Warsaw meetup
| tomorrow, feel free to join, especially if you're up for a live
| discussion later: https://www.meetup.com/Rust-
| Warsaw/events/282879405/
| gxt wrote:
| It's a great story and it's pleasant to see end-devs
| investigations contribute to the overall performance of the
| ecosystem since Tokio is so widely used. Cheers
| eminence32 wrote:
| Nice article, and nice analysis of the problem.
|
| I have a personal theory that once a codebase gets complicated
| enough (no matter the language, no matter sync or async), you'll
| run into subtle bugs or performance problems that require a very
| deep understanding of all the relevant libraries in order to
| resolve the problem. One worry that I have with async rust is
| that the executors are so complex that the "baseline complexity"
| starts rather high.
|
| If this theory is true, then one might expect async rust to run
| into such problems more often than comparable non-async code. I
| haven't personally written enough async code to have any data
| either way, except for a few unpleasant experiences while making
| errors when writing async code.
|
| To the extent that this theory is a problem that needs solving, I
| don't think there is a solution. But I do think that, over time,
| weird async footguns will become less and less frequent as
| projects like tokio continue their excellent engineering efforts
| to plug up any weak spots and make things more robust in general.
| marcus_cemes wrote:
| > One worry that I have with async rust is that the executors
| are so complex that the "baseline complexity" starts rather
| high.
|
| I completely agree, however I like that you have the option to
| swap out the executor for your own if the situation requires
| it, which I think concerns a very small number of applications.
| In other languages with a baked-in runtime you would be left
| trying to come up with workarounds to make it play nicely.
___________________________________________________________________
(page generated 2022-01-12 23:00 UTC)