3 ms·

> One of the first performance optimizations we did was accept that most object lifetimes roughly coincided with the end of the request, so we simply didn't dea

• nitrogen 9y ago
  The parent post said they used static linking to remove much of the process spawning overhead.
• vidarh 9y ago
  Our actual measurements and server loads proved otherwise. Actually, in reality things were exactly opposite of what you suggest: it provided no noticeable benefits for development, but massively improved performance in production. Spawning a process on Linux is more expensive than spawning a thread or reusing the same process via a fastcgi type setup, but it's not all that expensive when you're spawning a statically linked app with no complex startup code and the app is guaranteed to be in the buffer cache at any moment. What killed CGI for most uses was not process creation overhead, but dynamic linking and applications not written to take advantage of the fact they'd die quickly. We knew that because we actually measured first, before deciding what strategy to take. We got performance very close to a fastcgi type setup with the above method, and without the complexity of ensuring we didn't have any resource leaks anywhere. Doing the above was enough to bring process startup overhead sufficiently far down our list of performance issues that it was not worth optimizing further.