[performance] http response encoding / writing improvements #2374
Conversation
| data io.Reader, | ||
| length int64, | ||
| ) { | ||
| if length < 0 { |
There was a problem hiding this comment.
Should this be <= instead of <? Do we always set length to -1 when we don't know it?
There was a problem hiding this comment.
i mean a length of zero is a valid content-length, which might happen if say we just want to pass in an arbitrary reader + length (even if the reader contains zero data). -1 is a specifically invalid content-length so a useful flag to indicate non-standard behaviour
| buf := getBuf() | ||
|
|
||
| // Wrap buffer in JSON encoder. | ||
| enc := json.NewEncoder(buf) |
There was a problem hiding this comment.
We might want to do SetEscapeHTML(false) on JSON encoders, since we don't really need escaping of HTML characters within the JSON in this context (API).
There was a problem hiding this comment.
ooh i'm sure that should result in a small little performance boost too with less escape checking + handling to do 👀
There was a problem hiding this comment.
ah it seems some of our test JSON was expecting escaping, let me go through and fix those :p
|
Never mind, reading comprehension suffers on Monday morning. |
Description
This adds new wrapper functions within
internal/api/utilthat handle response writing with content type / length setting. Where possible these will stream responses, and an all cases except for pre-prepared byte slices has the addition of pooled memory buffers for response encoding (including by JSON and XML). And multiple cases this also enables the use of pre-prepared JSON responses to reduce unneeded encoding for simple but known cases.Checklist
Please put an x inside each checkbox to indicate that you've read and followed it:
[ ]->[x]If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).
go fmt ./...andgolangci-lint run.