autoheaders considerations

[dvv]

IMHO

• os.date(): precision is 1 second, calling for each request is expensive, a cache and 1 second interval timer would reduce the load;
• server header: default value may be cached instead of concatting for each request
• chunked response closure with \r\n\r\n\r\n: not too many CRLFs?
• body as table: body is treated as stream. another use case is pure array body table which would mean kinda io_list, to supply intact to luv_write() which could be modified to allow multiple buffers. this should speed up dramatically such use cases as html templating (a template runner could just map input chunks into resulting table of strings instead of accumulating resulting string)

What do you think?

[dvv]

the first two are addressed in https://github.com/dvv/moonslice-luv/commit/97fe8dae81d4df8d150e382f8c6ab232dbdaefd7

[dvv]

forth is addressed by https://github.com/dvv/moonslice-luv/commit/d5f9aaf95b8581cfbfc6acd847b1e35aeb7d1c74 -- i hesitate to make changes to luv_write to make it accept tables as chunk until it's said feasible

[creationix]

Caching the Server header value is fine. Caching the Date header smells like premature optimization. How expensive is it? What's the affect it has on performance.

On chunked encoding, I may have read the spec wrong, but this is how I read it and it works with curl as a client. If my implementation is wrong, I'm fine with changing it to be correct.

I think body as a table is a great idea. We'll have to see if it's faster to accept the table at the luv binding layer and have one uv_write call or handle the table at the stream layer and convert it to multiple writes. I'm hoping it's faster to have one uv_write call.

[dvv]

We could measure Date evaluation but I believe it is rather expensive as all that deals with complex stringification, even being done in C.

Passing multiple buffers to to uv_write showed significant speedup when I measured it in my early luv development. String concats are so slow in Lua.

Just FYU, noticed that presenting a readstream with a table with read key can be reduced to just read function per se, when analyzing what an app handler returns as response body. This would save us to treat returned table as pure io_list and simplify response logic.