Optimizing for the Speed of Light
bizcoder.com
Optimizing for the Speed of Light
1–10 of 19 posts
Re: Optimizing for the Speed of Light
#2Since the site doesn't load currently - which is a bit funny considering the title - archive.is comes to the rescue:
Re: Optimizing for the Speed of Light
#3> In C#/typescript you can no longer use the friendly `await` keyword that makes async calls almost as easy synchronous calls. Ironically, the `await` keyword makes it really easy to force HTTP requests to execute sequentially that could easily execute in parallel. This is what the pit of fail looks like!
I'm not specifically familiar with C# or typescript's async keyword implementations, but this.. shouldn't be true?
If you can't launch multiple requests and then gather their results either through aggregating to a single future or by awaiting on them individually (which will mean you will start acting on results somewhere between min(t1,t2,t3,..tn) and max(t1,t2,t3,..tn) time) while all of them proceed just as well as if you had done callbacks, that's not a very good implementation of async/await...
Re: Optimizing for the Speed of Light
#4The article overlooks the end-to-end overhead of HTTP/2 which unfortunately makes the trade-offs between batching API calls and bundling JavaScript very complex in practice. For instance in Chrome the overhead of an additional request is still several milliseconds of local CPU time. Which means in practice you'll trade off CPU time to benefit warm loads where the cache is populated.
I'm hopeful someday the overhead will be made negligible but until then I'd suggest profiling the trade-offs.
Meanwhile data frameworks like Relay offer incremental flushing with much more flexibility all over a single request.
Re: Optimizing for the Speed of Light
#5I think the guy needs to read a bit more physics. Electricity travels at about 2/3 the speed of light in copper wires.
Re: Optimizing for the Speed of Light
#6> In C#/typescript you can no longer use the friendly `await` keyword that makes async calls almost as easy synchronous calls. Ironically, the `await` keyword makes it really easy to force HTTP requests to execute sequentially that could easily execute in parallel. This is what the pit of fail looks like! I'm not specifically familiar with C# or typescript's async keyword implementations, but this.. shouldn't be true…
There are Task.WhenAll and Task.WhenAny, but I think GP is referring to it being easier to do the naïve thing and write sequential awaits instead.
Does anyone know if there are warnings or linters that will catch this in C#, at least if done within one function?
Re: Optimizing for the Speed of Light
#7I think the guy needs to read a bit more physics. Electricity travels at about 2/3 the speed of light in copper wires.
...and once you learn about physics you find out about orders of magnitude.
Re: Optimizing for the Speed of Light
#8> In C#/typescript you can no longer use the friendly `await` keyword that makes async calls almost as easy synchronous calls. Ironically, the `await` keyword makes it really easy to force HTTP requests to execute sequentially that could easily execute in parallel. This is what the pit of fail looks like! I'm not specifically familiar with C# or typescript's async keyword implementations, but this.. shouldn't be true…
There are Task.WhenAll and Task.WhenAny, but I think GP is referring to it being easier to do the naïve thing and write sequential awaits instead. Does anyone know if there are warnings or linters that will catch this in C#, at least if done within one function?
Agreed. But GP is correct in that you can't turn a C# async method into a sync call simply by awaiting it. Some good discussion on workarounds here [0]. That does seem "unfortunate" as it means async will grow through the codebase (the SO article refers to it as a "zombie virus"). If it's all code you're writing then you have options. But if you're using a 3rd party lib, and the author decided it should be async, then your code becomes transitively async too. Whether you want/need it or not.
That just doesn't seem like good language design. I totally get the need for concurrency, but the feature shouldn't have such an invasive impact on the code base. Go and Erlang manage to provide good concurrency support without the tax.
[0] https://stackoverflow.com/questions/9343594/how-to-call-asyn...
Re: Optimizing for the Speed of Light
#9Earlier quoted context omitted.
There are Task.WhenAll and Task.WhenAny, but I think GP is referring to it being easier to do the naïve thing and write sequential awaits instead. Does anyone know if there are warnings or linters that will catch this in C#, at least if done within one function?
Agreed. But GP is correct in that you can't turn a C# async method into a sync call simply by awaiting it. Some good discussion on workarounds here [0]. That does seem "unfortunate" as it means async will grow through the codebase (the SO article refers to it as a "zombie virus"). If it's all code you're writing then you have options. But if you're using a 3rd party lib, and the author decided it should be async, the…
Spawn a thread to await the async call and release a lock, block the main thread till the lock is released? What am I missing?
Re: Optimizing for the Speed of Light
#10> In C#/typescript you can no longer use the friendly `await` keyword that makes async calls almost as easy synchronous calls. Ironically, the `await` keyword makes it really easy to force HTTP requests to execute sequentially that could easily execute in parallel. This is what the pit of fail looks like! I'm not specifically familiar with C# or typescript's async keyword implementations, but this.. shouldn't be true…
[deleted]