On Mon 29 Jul 2013 11:25:14 AM PDT, Brendan Eich wrote:
> Steve Fink wrote:
>> On Mon 29 Jul 2013 10:43:27 AM PDT, Brendan Eich wrote:
>>> BTW destructuring plus array return should be optimized to erase the
>>> allocation and use the stack instead. E.g.,
>>>
>>> function pair(a, b) { return [a, b]; }
>>> let [x, y] = pair(z, w);
>>>
>>> should not allocate a fresh array in pair. Anyone know whether there's
>>> a bug asking for this?
>>
>> I don't know of a bug, but then, I wouldn't. (I don't even know that we
>> don't already do this.)
>>
>> This is what I was referring to when I said it would require inlining,
>> though. And in my case, the pair() function does a bunch of
>> computation, including several loops, before returning (or yielding).
>> Which probably means it won't be considered for inlining.
>>
>> Unless you're thinking of a more general optimization?
>
>
> If the function builds up a big array with random logic, then you need
> an allocation. That wasn't what you wrote:
Right, I'm not talking about building up an array. I'm talking about
function f() {
while (worklist.length > 0) {
...do some stuff...
if (found it)
return [ value1, value 2 ];
}
}
I'm saying that the presence of the loop inhibits inlining, and the
straightforward way to optimize away the temporary array creation is to
inline all of f() into its caller. I'm just saying this to clarify what
I was talking about; you're addressing exactly this in your next reply:
> Le 28/07/2013 08:53, Steve Fink a écrit :
>> * using an array for a tuple feels heavyweight. |return [a,b]|. Compare
>> with Python's tuples or Perl's multiple return values.
>
> OTOH, inlining is not required. Lars Thomas Hansen years ago talked
> about optimizing Scheme implementations (Larceny? Not sure), where the
> callee looks at its continuation and avoids the allocation
> collaboratively -- some kind of call PIC deal without the inlining
> being mandatory. Jim Blandy may know more ;-).
That would be cool. As an old-time Perl freak, I have to mention that
this reminds me of its user-visible dynamic context-dependence, where a
callee can do different things depending on what the caller is doing
with its return value. IIRC, Perl passes in a hidden context parameter
(mainly list vs scalar vs void), and the callee handles it on its own.
The JS solution has different constraints, though.
Alternatively, maybe we could think of this as inlining just the
return/yield statement into the caller. Though |return [a,b]| is pretty
different from |return f(a, b)|, so perhaps it's only |return
<literal-object-or-array>| that gets inlined.
I guess they're all just different ways of describing the same thing.
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
