lukechilds/node - node - Gitea: Git with a cup of tea

13287 Commits

131 Branches

446 Tags

325 MiB

Tree: 7fc6645982

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Rich Trott	4bb529d972	benchmark: use strict mode Apply strict mode to benchmark code. PR-URL: https://github.com/nodejs/node/pull/5336 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Roman Reiss <me@silverwind.io> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>	9 years ago
Brendan Ashworth	083c421b5c	benchmark: remove extra spacing in http options This commit removes the benchmark spacing modification in `client-request-body.js` and `end-vs-write-end.js` which adds two spaces to the end of some variables to make sure the lines line up. The reason behind this is that its totally pointless (the lines don't actually line up with it) and it disallows you to parse the output with a tool like awk, or at least makes it a lot harder. PR-URL: https://github.com/iojs/io.js/pull/650 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>	10 years ago
Ben Noordhuis	fda2b319dc	http: save roundtrips, convert buffers to strings This commit adds an optimization to the HTTP client that makes it possible to: * Pack the headers and the first chunk of the request body into a single write(). * Pack the chunk header and the chunk itself into a single write(). Because only one write() system call is issued instead of several, the chances of data ending up in a single TCP packet are phenomenally higher: the benchmark with `type=buf size=32` jumps from 50 req/s to 7,500 req/s, a 150-fold increase. This commit removes the check from `e4b716ef` that pushes binary encoded strings into the slow path. The commit log mentions that: We were assuming that any string can be concatenated safely to CRLF. However, for hex, base64, or binary encoded writes, this is not the case, and results in sending the incorrect response. For hex and base64 strings that's certainly true but binary strings are 'das Ding an sich': string.length is the same before and after decoding. Fixes #5528.	12 years ago

Rich Trott

4bb529d972

benchmark: use strict mode

Apply strict mode to benchmark code.

PR-URL: https://github.com/nodejs/node/pull/5336
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

9 years ago

Brendan Ashworth

083c421b5c

benchmark: remove extra spacing in http options

This commit removes the benchmark spacing modification in
`client-request-body.js` and `end-vs-write-end.js` which adds two spaces
to the end of some variables to make sure the lines line up.

The reason behind this is that its totally pointless (the lines don't
actually line up with it) and it disallows you to parse the output with
a tool like awk, or at least makes it a lot harder.

PR-URL: https://github.com/iojs/io.js/pull/650
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

10 years ago

Ben Noordhuis

fda2b319dc

http: save roundtrips, convert buffers to strings

This commit adds an optimization to the HTTP client that makes it
possible to:

* Pack the headers and the first chunk of the request body into a
  single write().

* Pack the chunk header and the chunk itself into a single write().

Because only one write() system call is issued instead of several,
the chances of data ending up in a single TCP packet are phenomenally
higher: the benchmark with `type=buf size=32` jumps from 50 req/s to
7,500 req/s, a 150-fold increase.

This commit removes the check from e4b716ef that pushes binary encoded
strings into the slow path. The commit log mentions that:

    We were assuming that any string can be concatenated safely to
    CRLF.  However, for hex, base64, or binary encoded writes, this
    is not the case, and results in sending the incorrect response.

For hex and base64 strings that's certainly true but binary strings
are 'das Ding an sich': string.length is the same before and after
decoding.

Fixes #5528.

12 years ago

3 Commits (7fc6645982855ced40bf4af4b002a30b30510ac0)