| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
You can avoid double negative stuff here, if you simply name it as should_assert or something like that.
Sorry, something went wrong.
There was a problem hiding this comment.
It is named this way to maintain consistency with the existing JS api.
Sorry, something went wrong.
There was a problem hiding this comment.
@matthewloring I think the convention in C++ is to use snake case for local variables and I am more interested in something like this
bool should_assert = !args[3]->BooleanValue();
...
if (should_assert) {
...
}
Sorry, something went wrong.
There was a problem hiding this comment.
It is convention to use snake_case in native code, and since I've been bitten in the butt by it before (in buffer code actually) I'll have to agree with @thefourtheye's observation of avoiding double negative is a better option.
Also, we'll need to do some benchmarking on BooleanValue(). Last time I used it (way way back in v0.10) the performance was bad enough that we actually prefixed the check with IsUndefined(). So may look something like this:
bool should_assert = !args[3]->IsUndefined() && !args[3]->BooleanValue();Think that's right, but it's getting late.
Sorry, something went wrong.
There was a problem hiding this comment.
I believe the condition should be args[3]->IsUndefined() || !args[3]->BooleanValue(). Alternatively, we could use !! on the JS side to ensure we only get booleans at this point the same way the other arguments are type coerced value = +value; offset = offset >>> 0;. Do you have a preference between these?
Sorry, something went wrong.
There was a problem hiding this comment.
In the mean time, I've fixed the case and negation issues here.
Sorry, something went wrong.
There was a problem hiding this comment.
These v8::Value::XValue methods are scheduled for deprecation in favor of the Maybe versions.
Sorry, something went wrong.
There was a problem hiding this comment.
I've updated the value accesses in this function to use the new version. It looks like the non-Maybe versions are still used elsewhere throughout the file.
Sorry, something went wrong.
There was a problem hiding this comment.
@matthewloring From my distant memory it was indeed faster to coerce noAssert in JS. Then you can do a simple IsTrue() check, and drop the other two.
Sorry, something went wrong.
There was a problem hiding this comment.
@trevnorris I've moved the boolean coercion into JS.
Sorry, something went wrong.
There was a problem hiding this comment.
Drop the CHECK_LE below the conditional check. We still want to abort to prevent writing to memory bits we don't have control over.
Sorry, something went wrong.
There was a problem hiding this comment.
NM this comment. Logic will change w/ another upcoming PR.
Sorry, something went wrong.
|
@matthewloring Awesome job. Thanks much for taking care of this. Has been one of those changes in my backlog that never taken the time to get to. Since this is all about micro-optimization (we'll only be shaving off 20ns or so here) there may be some experimentation we'll need to do |
Sorry, something went wrong.
|
@matthewloring There's going to be a collision with #3767. It only touches the location where you removed the CHECK_LE. Mind if I proceed with that one, the we rebase this one and continue to make things fast? EDIT: Ref'd issue was this one. Has been fixed. |
Sorry, something went wrong.
|
@trevnorris It should be an easy merge conflict to resolve. You're welcome to land #3767. |
Sorry, something went wrong.
There was a problem hiding this comment.
sorry, minor nit: do the boolean coercion in the call itself. e.g. writeFloatBE(this, val, offset, !!noAssert);
Sorry, something went wrong.
There was a problem hiding this comment.
Inlined.
Sorry, something went wrong.
|
Looks great. As soon as I can land the previously mentioned patch, get this rebased and CI is happy we'll be good to land. LGTM. |
Sorry, something went wrong.
There was a problem hiding this comment.
Why does this function take the T parameter? T is used as the return type for v8::Value::NumberValue::FromMaybe, which returns a double.
Sorry, something went wrong.
There was a problem hiding this comment.
val may either be a double or float.
Sorry, something went wrong.
|
LGTM |
Sorry, something went wrong.
|
@trevnorris ... as an optimization, I'm inclined not to flag this for LTS but would like your input on that. |
Sorry, something went wrong.
|
@jasnell Sounds reasonable. I think this is low risk, but also not critical. |
Sorry, something went wrong.
Sorry, something went wrong.
|
Looks like this may be integer overflow on 32-bit architectures? I can verify and put together a fix. |
Sorry, something went wrong.
|
@matthewloring ping me when you have a fix, or have a question, and will run CI again. |
Sorry, something went wrong.
|
@trevnorris I've added the lower bounds check which I believe to fix the problem but do not have a centos 32 vm to reproduce the initial failure on. Are there existing overflow prevention checks elsewhere inside buffer that I should emulate or does the added check CHECK_NOT_OOB(offset + sizeof(T) >= sizeof(T)); at line 745 seem good? If so, it's ready for another CI. |
Sorry, something went wrong.
Sorry, something went wrong.
|
The test-crypto-dh.js timeouts are happening on a few machines but it should be unrelated. |
Sorry, something went wrong.
|
@matthewloring Just landed the other conflicting PR. Mind rebasing on latest master? The other PR alerted me to the specific wording in the current documentation:
So I believe if noAssert is set and the offset is beyond the bound of the buffer we simply return early. Though I'd still leave in that specific CHECK just to make sure any future modifications don't accidentally allow writing beyond memory bounds. |
Sorry, something went wrong.
|
@trevnorris I've rebased and reinserted the CHECK_LE just as a failsafe. Should be good to go. |
Sorry, something went wrong.
Sorry, something went wrong.
|
Failures (mostly crypto timeouts) should be unrelated flakes. |
Sorry, something went wrong.
|
@matthewloring We'll need to do some investigation. The call is slower than it is now. This is the fun part. :) I'll update if I find any details. Here's a simple script I'm using: 'use strict';
const ITER = 1e7;
var b = new Buffer(8);
var t = process.hrtime();
for (var i = 0; i < ITER; i++) {
b.writeDoubleLE(0, 0, true);
}
t = process.hrtime(t);
console.log(((t[0] * 1e9 + t[1]) / ITER).toFixed(1) + ' ns/op');(note: this is fine b/c the call into native isn't affected by the optimizing compiler like JS would be) |
Sorry, something went wrong.
|
Hmm, I can look into this as well. |
Sorry, something went wrong.
|
It looks like at least part of the slow down is caused by the new maybe versions of NumberValue and Uint32Value. I see ~53 ns/op with the maybe versions compared to ~46 ns/op with the old versions of NumberValue and Uint32Value and ~44 ns/op with the checks remaining in JS (at master). |
Sorry, something went wrong.
|
@matthewloring Here's a diff gaining back the lost performance: https://gist.github.com/trevnorris/3bce2822893a98e9d971 Sorry, this is where writing performant code makes things look worse. |
Sorry, something went wrong.
|
The new Maybe versions definitely aren't helping. Also getting the values out (e.g. NumberValue() are taking longer than I'd expect). |
Sorry, something went wrong.
The type and range checks performed by this function can be done more efficiently in native code.
|
That change brings script down to ~42 for me. I've applied your change. |
Sorry, something went wrong.
Sorry, something went wrong.
|
Only failure is a child process fork connection reset, seems good to me. |
Sorry, something went wrong.
The type and range checks performed by this function can be done more efficiently in native code. PR-URL: #3763 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The type and range checks performed by this function can be done more efficiently in native code. PR-URL: #3763 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
Marking with dont-land-on-v4.x but noting that above discussion suggests that this could be a candidate if we changed our risk profile for LTS. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The type and range checks performed by this function can be done more
efficiently in native code.
/cc @trevnorris