Thanks, Lasse. I'll prepare a CL cleaning up all the stuff you mentioned
and
run it through perfbots.
http://codereview.chromium.org/1513020/diff/7001/8001
File src/array.js (right):
http://codereview.chromium.org/1513020/diff/7001/8001#newcode649
src/array.js:649: var element = a[i];
On 2010/04/07 17:43:27, Lasse Reichstein wrote:
Come to think of it, using binary search seems overkill, since we are
going to
read and write every element after the found position anyway when we
place the
element.
Just do a backwards search-and-copy until finding the correct
location. I.e,
something like:
for (var j = i - 1; j >= from; j--) {
var tmp = a[j];
var order = tmp === element ? 0 :
comparefn.call(null,tmp,element);
if (order > 0) {
a[j + 1] = tmp;
} else if (order == 0) {
j--;
break;
}
}
a[j + 1] = element;
Agree. That's the thing I implemented in C++, but calling JS from C++
is expensive. I'll give it a try, but for now it doesn't look like the
main reason for slowness.
http://codereview.chromium.org/1513020/diff/7001/8001#newcode658
src/array.js:658: 0 : comparefn.call(null, a[mid], element);
On 2010/04/07 17:43:27, Lasse Reichstein wrote:
Reading a[mid] twice. Maybe assign to temporary variable.
Thanks, will give it a try.
http://codereview.chromium.org/1513020/diff/7001/8001#newcode660
src/array.js:660: min = max = mid;
On 2010/04/07 17:43:27, Lasse Reichstein wrote:
No need to assign to max.
Will give it a try as well.
http://codereview.chromium.org/1513020/diff/7001/8001#newcode716
src/array.js:716: // If it isn't, we are allowed arbitrary behavior by
ECMA 15.4.4.11.
On 2010/04/07 17:43:27, Lasse Reichstein wrote:
Comment doesn't make sense any more (not here, at least).
Agree. Will remove.
http://codereview.chromium.org/1513020
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
To unsubscribe, reply using "remove me" as the subject.
