Why speed up asynchronous programming
It's not faster, it just doesn't waste time.
Synchronous code stops processing while waiting for I / O. This means that when you read the file, you cannot run any other code. Now, if you have nothing to do while this file is being read, asynchronous code won't buy you anything.
Usually the extra CPU time you can use is beneficial for servers. So the question is why asynchronous programming instead of starting a new thread for each client?
It turns out that starting and breaking the threads of the roads. Some time ago in the early 2000s, a web server test found that tclhttpd compares favorably with Apache for handling static image files. This is despite the fact that tclhttpd was written in tcl and Apache was written in C and tcl was known to be 50 times slower than C. Tcl managed to keep its own against Apache because tcl had an easy-to-use asynchronous API input-output. So tclhttpd used it.
This is not to say that C does not have an asynchronous I / O API. It's just that they are rarely used. So Apache didn't use it. Apache2 these days uses asynchronous I / O internally along with thread pools. C code looks more complex but faster is a lesson learned.
This brings us to our recent obsession with asynchronous programming. Why are people obsessed with this? (Most of the answers on Stackoverflow about javascript programming, for example, insist that you should never use synchronous versions of asynchronous functions).
This refers to how you rarely see asynchronous C programs, even if this is the best way to do things (GUI code is an exception because the UI libraries learned early on about relying on asynchronous programming and events). There are too many functions in C that are synchronous. Therefore, even if you want to do asynchronous programming, you will end up calling the synchronous function sooner or later. The alternative is to ditch stdlib and write your own asynchronous libraries for everything from file I / O to SQL networking.
So in languages like javascript, where asynchronous programming ends up as the default style, there is pressure from other programmers not to mess it up and accidentally introduce synchronous functions that are difficult to integrate with asynchronous code without losing a lot of performance. Thus, in the end, like taxes, asynchronous code became a social contract.
source to share
It's not always faster. In fact, just setting up and disabling the async environment adds a lot of time to your code. You need to spin off the new process / thread, set up the event / message queue pump and clear everything at the end. (Even if your structure hides all these details from you, they happen in the background).
Blocking is an advantage. Most of our code depends on external resources. We need to query the database to process the records or download the latest version of something from the website. From the moment you request this resource for information to receive a response, your code is irrelevant. It blocks, waiting for a response. Your program spends all the time on blocking completely.
What is asynchronous mode for? By turning the "wait this this blocking" code into an async request, you leave the rest of your non-blocking code.
As a metaphor, imagine a manager telling his co-worker what to do on that day. One of the challenges is making a phone call to a company with long waiting times. If he told her to make the call synchronously, she would call and wait, without doing anything else. Make it asynchronous and it can work on a variety of other tasks while the phone is on hold in the background.
source to share