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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 18 06:04:46 PDT 2014


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


Kyle Simpson <getify at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |getify at gmail.com




--- Comment #8 from Kyle Simpson <getify at gmail.com>  2014-06-18 06:05:04 PST ---
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.



More information about the webkit-unassigned mailing list