That library rarely does type checking. This contributes a lot of
speed to their overall algorithm. If you look at my benchmarks,
clearly, removing type checking helps, but it doesn't help for all
applications. Another thing is that they use 99% C-style for loops
with numerical indices instead of for-in loops (which always require
some type checking because they work with all Objects and Arrays). The
code actually resembles Asm.js in its heavy use of numbers.
Array#[push|pop]() is easily optimized for array instances, because
they each compile down to a single common assembly instruction. Also,
in the case of Array#pop(), if the value isn't used, then it can
simply pop to the same register over and over again, making it easily
surpass 100 million operations per second if properly optimized.
Back to the initial topic, my main request isn't to remove
type-checking, but to make a special case (or more optimal case) for
Arrays in Array#join(), and especially if it is an array of Strings.
This is a relatively fast snippet of C++ code:
std::string join(std::string* array, int len) {
std::string str = '';
while (len) {
str += *(array + --len);
}
return str;
}
The Fast library could speed up some of their methods easily by
reversing the iteration order for some methods (and I'm about to draft
a quick patch to it).
On Sun, Aug 31, 2014 at 9:22 AM, Jacob G <[email protected]> wrote:
> You should take a look at this too: https://github.com/codemix/fast.js -
> Functions written in JS are faster than the native functions. Is there
> something to be done?
>
> Am Sonntag, 31. August 2014 02:16:37 UTC+2 schrieb Isiah Meadows:
>>
>> I profiled various native methods, comparing them to equivalent polyfills
>> and special-cased ones. I compared the following functions:
>>
>> Math.abs(x)
>> Array.prototype.pop()
>> Math.ceil(x)
>> Array.prototype.join(sep)
>>
>> I found the following things from testing in various browsers:
>>
>> Math.abs(x)
>>
>> Webkit is about twice as fast as V8 in the native implementation.
>> Webkit's performance in the rest is on par with V8's.
>> Similar performance between type-ignorant polyfills and native
>> implementation (on all browsers)
>>
>> Array.prototype.pop()
>>
>> Firefox clearly hasn't optimized the special case for arrays natively.
>> JS polyfills are insanely slow, with type checking making little
>> difference.
>>
>> Math.ceil(x)
>>
>> JS polyfills significantly slower, but that is explainable with the better
>> bitwise ability with floats/doubles/etc. in C/C++.
>>
>> Mine does it without branching, but a potentially better way is to
>> decrement if less than 0 and truncate it.
>>
>> Webkit is a little faster, but not a lot.
>>
>> Array.prototype.join(sep)
>>
>> JS standards polyfill rather slow
>> JS polyfill assuming an array is over twice as fast as the native
>> implementation (If it optimizes for this case, it should structurally
>> resemble a Java Object[] internally).
>>
>> This really needs a special case (or better special case) for Arrays.
>>
>> I can't a patch for this yet, because of current CLA confusion
>> (off-topic), but it should be relatively simple.
>
> --
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/v8-users/FoK9X52cIDs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
Isiah Meadows
--
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
