Post B7xgvFaL26gqYg8wrY by navi@social.vlhl.dev
 (DIR) More posts by navi@social.vlhl.dev
 (DIR) Post #B7xgvFaL26gqYg8wrY by navi@social.vlhl.dev
       2 likes, 0 repeats
       
       fork + exec continues to prove itself slow as fuck, even with CoW
       
 (DIR) Post #B7xgwAoqEr9y4AMpsm by newt@stereophonic.space
       0 likes, 0 repeats
       
       @navi nuke it from orbit
       
 (DIR) Post #B7y2XCWaxRaz6mKWVU by ska@social.treehouse.systems
       1 likes, 0 repeats
       
       @koorogi @navi Yup. IIRC, it was when I was writing tipidee (my web server) and wanted to optimize s6-tcpserver to make the most of the "one connection = one process" model. So I rewrote the s6-tcpserver algorithm to be O(n log n) rather than O(n²) in number of connections, and benchmarked it. There was barely any performance difference either way and the logarithmic algorithm only won starting around n=4k. Then, as an experiment, I rewrote it to use posix_spawn instead for fork+exec... and this time the performance difference was immediate and incredible. I shared that on #musl and @dalias (or was it nsz?) explained the CoW thing. I remembered being very surprised that fork was the costly system call rather than execve; that sounded counter-intuitive but the needed preparation (and fallout) in the parent makes sense.Following that, I switched all my software to use posix_spawn wherever possible and am still giddy about it.