The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
Replace the call to Array#splice() with a faster open-coded version
that creates less garbage.
Add a new benchmark to prove it. With the change applied, it scores
about 5% higher and that is nothing to sneeze at.
PR-URL: https://github.com/iojs/io.js/pull/184
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Replace the call to Array#splice() with a faster open-coded version
that creates less garbage.
Add a new benchmark to prove it. With the change applied, it scores
a whopping 40% higher.
PR-URL: https://github.com/iojs/io.js/pull/185
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Force V8 to optimize url.parse() before starting the actual benchmark.
Tries to minimize variance between successive runs caused by the
optimizer kicking in at different points.
It does not seem to have much impact, CPU times are roughly the same
before and afterwards; url.parse() quickly plateaus at a local optimum
where most time is spent in V8 builtins, notably Runtime_StringSplit()
and Object::GetElementWithReceiver() calls originating from
deps/v8/src/uri.js, with no recurring optimize/deoptimize cycles that
I could spot.
Still, I don't see any downsides to pre-optimizing the function being
benchmarked so in it goes.
PR-URL: https://github.com/iojs/io.js/pull/132
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Adds the feature to define arguments for the function called in
domain.run(), this is supposed to be useful when a function is called from
another context and some values from the current context are needed as
arguments, it's similar to the callback from setTimeout or setInterval.
PR-URL: https://github.com/iojs/io.js/pull/15
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Adds a test for benchmarking the module loader, needed for benchmarking
changes / refacortings in the module loader.
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Timothy J Fontaine <tjfontaine@gmail.com>
The test is supposed to measure the performance of the base64 encoder
so move the Buffer#write() calls out of the benchmark section.
The overhead of the calls isn't terrible (about 1-3%) but having
unrelated activity in a micro-benchmark is never a good idea.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
compare() works like String.localeCompare such that:
Buffer.compare(a, b) === a.compare(b);
equals() does a native check to see if two buffers are equal.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Increase the performance and simplify the logic of Buffer#write{U}Int*
and Buffer#read{U}Int* methods by placing the byte manipulation code
directly inline.
Also improve the speed of buffer-write benchmarks by creating a new
call directly to each method by using Function() instead of calling by
buff[fn].
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Since the SlabAllocator was removed the buffer length/offset is no
longer sent to the onread callback. The benchmarks have been updated to
reflect that.
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.
The benchmark compare would drop the last run of the binary pairs. So
when they were only run once an error would arise because no data was
generated for the second binary.
The benefits of the hot-path optimization below start to fall off when
the buffer size gets up near 128KB, because the cost of the copy is more
than the cost of the extra write() call. Switch to the write/end method
at that point.
Heuristics and magic numbers are awful, but slow http responses are
worse.
Fix#4975
This will run the benchmarks the number of times specified by NODE_BENCH_RUNS,
to attempt to reduce variability.
If the number of runs is high enough, it'll also throw out the top and bottom
quartiles, since that's where the outliers will be.
It's not very fancy statistics-fu, but it's better than nothing.
Also, linted this file. It had tabs in it. TABS!
For throughput benchmarks, run with just 5s durations rather than 1s and 3s.
For startup benchmark, run with just a single 1s duration, since it's very
consistent anyway.
Yosuke Furukawa