> Array#[push|pop]() is easily optimized for array instances, because
> they each compile down to a single common assembly instruction
Last time I checked Intel manual it did not have jsapop/jsapush
instructions.
You need to do a bit of checks (length underflow, lack holes in the array,
etc). So a single instruction is unlikely (though potentially possible in a
loop under certain conditions --- but those conditions require
sophisticated optimizations to achieve, e.g. you need to hoist bounds
checks and sink update of length out of the loop, etc.).
> but to make a special case (or more optimal case) for Arrays in
Array#join(), and especially if it is an array of Strings.
There is such case. It's called _FastAsciiArrayJoin.
> This is a relatively fast snippet of C++ code:
This might have O(n^2) runtime complexity or waste memory for result (if
library does capacity doubling on appends, which is common strategy)
depending on how your C++ library reserves capacity for std::string.
std::string join(const std::vector<std::string>& array) {
size_t total_length = 0;
for (auto& s : array) total_length += s.length();
std::string str;
str.reserve(total_length);
for (auto& s : array) str.append(s);
return str;
}
which is btw exactly what _FastAsciiArrayJoin attempts to do.
Vyacheslav Egorov
On Mon, Sep 1, 2014 at 11:20 AM, Isiah Meadows <[email protected]> wrote:
> 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.
>
--
--
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.
