I agree, I view dead code at run-time as a liability. Something that can go
wrong. At compile time, you know everything about the sytem, the config
script makes assumptions and the binaries shouldnt work if moved to a
different OS etc anyway.
I am not a nginx developer just a C++ developer.
On M
1. Amount of instructions is somewhat bigger - about 500 bytes.
2. In high load you have thousands of accept()s per second.
3. No, I do not talk about adding some code, conversely - actually I want
remove dead code! :)
> Frankly, I don't see the need. We're talking about eliminating 4 or 5 CPU
> i
Frankly, I don't see the need. We're talking about eliminating 4 or 5 CPU
instructions per accept() call which only seems relevant if that's the only
thing nginx does: but with HTTP pipelining this optimization is very
insignificant as that already reduces the amount of accept() calls a lot. Als
I think it is not a matter for trade - "dead code" - is bad programming
technique. And it should be eliminated in a fast web server.
Of course, general impact on overall performance is not significant, but
on function level it will be much noticeable. I can make a perf profiling
test to get exact c
Hello!
On Mon, Aug 05, 2013 at 12:15:04AM +0300, Serguei I. Ivantsov wrote:
[...]
> A little test with high volume of simple requests shows 0.5% overall speed
> improvement.
Are you sure the numbers are significant? Doing a ministat(1)
analysis or similar is a good idea.
http://www.freebsd.o
Hi,
While researching nginx, I found that there are a lot of dead code, mostly
in ngx_event_accept.c
One of those blocks:
if (ngx_event_flags & NGX_USE_RTSIG_EVENT) {
ev->available = 1;
} else if (!(ngx_event_flags & NGX_USE_KQUEUE_EVENT)) {
ev->available = ecf->multi_acce
