Title is actually "Fibers are the Right Solution" and the article ends with "Fibers are the best solution for composable, scalable, non-blocking clients and servers."
The title as posted is most definitely not true. I have worked on high volume Ruby applications where the problem with using async I/O combined with poor raw execution of Ruby code resulted in excess garbage to be collected. Ruby performance should mean the performance of executing Ruby code. Perhaps the title could have been 'Ruby webapp performance'.
> I have worked on high volume Ruby applications where the problem with using async I/O combined with poor raw execution of Ruby code resulted in excess garbage to be collected.
What async I/O approach did you use and where did the garbage come from? I/O buffers?
It was an api endpoint making a number of db and other network requests. The garbage was the accumulation of temporary and response objects that were held for the long duration of processing, up to half of which could be in the ruby code not waiting on i/o. If the code ran faster there would be more time for gc and handling the incoming request volume.
The title as posted is most definitely not true. I have worked on high volume Ruby applications where the problem with using async I/O combined with poor raw execution of Ruby code resulted in excess garbage to be collected. Ruby performance should mean the performance of executing Ruby code. Perhaps the title could have been 'Ruby webapp performance'.