[barrkel]

The closer you are to a release, the bigger the blocker needs to be. If there was incorrect behaviour in a mainline use case, that would be much more significant than a performance regression.

A 20% performance regression in a minimal http server (i.e. one that doesn't have any business logic) does not sound like a big problem to me; that kind of overhead would normally be dwarfed by database calls, and a 20% increase in the overhead doesn't sound like it's a large increase in what I'd expect to already be a very small number.

[reimertz]

Thanks for the clarification.

So a similar situation in node.js-land would be if require('http') would get a worst-case scenario of a 20% performance hit, right?

If this is the case, even I, who only run single instances of node, would think it would be a fairly big impact that i'd try to fix if I was the maintainer and still had the possibility to fix it.

[Vendan]

The issue is that's it's 20% of the http library's time, not 20% of your application's time. Put a large app on it, and now the regression is 0.02%... Does it still make sense to push everything back for that 0.02%?