[Webkit-unassigned] [Bug 80797] Argument length limited to 65536

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=80797





--- Comment #9 from Oliver Hunt <oliver at apple.com>  2014-06-18 10:08:28 PST ---
You can't expect arbitrarily large argument lists in any implementation - generally that's not the purpose of .apply (you could use spread as well).  We also can't detect the call to push in advance as we don't know we're in push until after we've already called it, and that means we have to have already copied your argument array onto the stack.

> Just noting another use-case (specifically around performance) where this limitation is... unfortunate.
> 
> If I have two arrays and I want to merge them together, there's these options:
> 
>   A = A.concat(B)
> 
> vs
> 
>   A.push.apply(A,B)
> 
> 
> The former is obviously more idiomatic, but it also has the unfortunate side-effect of creating a new merged array rather than adding onto the existing one. So, if you have a "big" array A, you end up duplicating the A, and then GC throwing away the previous one.
> 
> In those cases, the `A.push.apply(A,B)` would be more ideal since it modifies A in place, which prevents the memory duplication and prevents the GC'ing.
> 
> But now, obviously, the size of B is limited to ~65k items.
> 
> That still is sorta OK if A is "big" but B is, relatively speaking, "small". But it is still highly unfortunate that code would have to know implementation-dependent limits on such things.
> 
> I wonder if it would be possible for an implementation to detect such an push.apply(..) case and handle it more gracefully to work-around the limitation of how many params can be passed. It could see "wow, B is really big, we can't pass it in all at once, but we can rewrite it internally to the rough equivalent of..."
> 
> A.push.apply(A,B) -->
> 
> for (var len=B.length, s = 0, m; s<len; ) {
>    m = Math.min(s+65000,len);
>    A.push.apply(A,B.slice(s,m));
>    s = m;
> }
> 
> 
> 
> ------
> 
> I see this as similar to the restriction on call-stack size when using recursion. If I write a recursive algorithm that should be TCO, but it runs in a browser that doesn't have that capability, it could fail. It's unfortunate that I have to know and guard against such things.
> 
> That's why seeing ES6 mandate TCO (they are still doing that, right!?) was so nice, because it signals a time in the future when there's a very valid programming technique which will no longer be susceptible to arbitrary, implementation-dependent limitations.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.