A question about the benchmark

[y2q-actionman]

I have a question about the benchmark of the README. Briefly saying, "How much memory your fast-http use?". Below, I describe the reason why I argue it.

I looked the http-parser of C, and I noticed it takes great effort to use less and less memory. The README of http-parser says, "it only requires about 40 bytes of data per message stream". And, by looking its codes, it tries to be less stack allocation, and to make a smaller object file after compilation.

Using less memory is generally bad for speed at runtime. As far as I saw, these points in http-parser are quite bad for speed (but good for less memory).

1. Using bit-fields for struct members.

   You know, accessing bit-fields is slow.

2. Using less local variables.

   Especially, it don't use a local variable for controlling. This is obviously bad for speed.

3. Not inlining too much code.

   One way to optimizing a state-machine is using the 'direct threaded code' technique. (I think you used this technique for your fast-http). If control-flows are taken into codes, the code will be faster, and larger.

By the way, the README of your fast-http doesn't say about its memory usage. So, I checked memory usages of these systems.

	http-parser	fast-http	customized C
parser struct size	32	112	48
code size	13355	> 41556	15243
stack usage of parser	104	16	88
stack usage of URL parser	40	16	40
any other functions	0	16	0
'Elapsed Time'	0.2924059	0.1169	0.1053272

All 'size' are taken at x86-64 MacOS X 10.9 At http-parser, 'code size' is the size of the entire system. At fast-http, the 'code size' is only for the 'http-parse' function. The size of the entire system is much more.

('customized C' is the C http-parser I customized to remove bad points for speed. In exchange for a bit more memory, it works more faster. code is here: https://github.com/y2q-actionman/http-parser/tree/direct-threaded )

The speed of http-parser is obviously restricted by its small memory, but I think this is intended and designed. So, comparing two systems only with the speed is quite unfair for the http-parser. I think you should say something about the fact that your fast-http spends more memory than the http-parser. (Moreover, the README of http-parser doesn't feature its speed!)

Thank you for reading.

[fukamachi]

Thank you for pointing out and simple descriptions. I added a note about memory usage at README.

[fukamachi]

It's just for curious, but could you explain why they think memory usage is more important than speed? I think Node.js doesn't have threads and many parsers won't work in the same time.

[y2q-actionman]

Sorry, I don't know about the architecture of Node.js. My wording for http-parser is derived only from its repository.

[guicho271828]

@y2q-actionman what happens if you changes (space 0) to (space 3)? worth a try.