fukamachi / fast-http

A fast HTTP request/response parser for Common Lisp.
343 stars 37 forks source link

A question about the benchmark #8

Closed y2q-actionman closed 10 years ago

y2q-actionman commented 10 years ago

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 commented 10 years ago

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

fukamachi commented 10 years ago

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 commented 10 years ago

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

guicho271828 commented 9 years ago

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