On Sun 28 Jul 2013 05:06:33 AM PDT, David Bruant wrote:
> 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.
> The "tradition" in JS is to return an object and give names to the
> keys. It usually makes the code more readable as one doesn't need to
> remember the semantics of each field ("is the second element of the
> array to latitude or longitude?")Ok, fair enough. It tickles my innate premature optimization kneejerk reaction, though. Either of these approaches explicitly creates a temporary object, increasing GC pressure etc. It'd be nice to have something that, while it *may* create a temporary internally, isn't required by the semantics so I get the warm fuzzy feeling that the compiler/VM could optimize it away down to a pair of registers or something. I suppose that still may be true if the compiler inlines these things, but the code returning the tuple often isn't small (in particular, it frequently has loops, especially when you're yielding.) But for now, I think you're right. I'll switch to returning named object fields and destructuring at least until I notice a speed hit. >> * Not a language issue, but I really like the cleaner control flow and >> intermediate memory usage of generators. But I am avoiding them in hot >> code because neither ionmonkey nor baseline currently gets along with >> them. (As in, they don't compile them, so I've been advised to avoid >> them when I don't want a performance cliff.) > :-/ I would take the other road, that is: use them as you need and > create a benchmark out of your real code so that IonMonkey and > Baseline have an actual use case (and motivation!) to optimize. > Chicken and egg problem, but if no one uses them, they'll never get > optimized. I always have noble intentions of doing something like this, and even tag my mq repo when I hit something that feels like a good benchmark case. But when the speed hit means 2 analysis runs a day instead of 8, I can't afford to let benchmarking get in the way of production. Which means that the benchmark version rots away, as it is dependent on unstable JS shell-only features. > On a related note, has the SpiderMonkey team heard of JSRegress > [2][3][4]? I think I've stumbled across it before, but have never really looked. I can't speak for anyone else. We do have a collection of assorted tests that arewefastyet runs, which I believe is intended for a similar purpose. See <http://arewefastyet.com/#machine=11&view=breakdown&suite=misc> and <https://bugzilla.mozilla.org/show_bug.cgi?id=649487>. I don't know much about it, though. >> * Extending an array via |combined = orig.concat(newstuff)| creates >> garbage, can't be used when updating the original is what you want, and >> concat behaves differently for arrays vs everything else. (I don't know >> the spec well enough to understand what "array" means in this case.) >> Compare with Python's orig.extend(newstuff) and Perl's push @orig, >> @newstuff. > Little known fact: Array.prototype.push is variadic, so you can do: > > Array.prototype.push.apply(orig, newstuff) // ES5 Hm. I knew about that at one point, and even used it. It reads pretty awfully, and isn't the first thing that comes to mind. > > or > > orig.push(...newstuff) // ES6 assuming Now *that* is nice, and would resolve my complaint. I think I once even tried |orig.push(*newstuff)| (I've been learning Python and JavaScript in parallel for the last few years, so I often mix them up.) Sadly, that currently hangs my shell. > https://bugzilla.mozilla.org/show_bug.cgi?id=762363 Perhaps that's why. :-) >> * undefined testing. It bothers me that |undefined| can be defined, so >> |x === undefined| isn't 100% guaranteed to mean what I want (and yet >> redefining undefined doesn't do anything useful.) > ES5 made 'undefined' an own non-configurable, non-writable value > proproperty of the global object. So the global undefined variable > can't be changed; guaranteed per spec. http://es5.github.io/#x15.1.1.3 > Changes to the "undefined" variable can only happen if someone changes > the value in one of your function scopes. If you control your scopes, > you control the value of the undefined variable. (basically, if in > your file, no function declares an "undefined" variable or argument, > the value is guaranteed to be the global one and not to change > according to the above point). Yeah, I know. It's just that the caveats are too complex, even if they are pretty tight. And I still don't like using a value comparison to test for definedness. Using typeof() is better from that standpoint, but speaking of clunky-feeling things, string comparisons for fundamental stuff are also in that bucket. This makes me think that I should just define my own function defined(x) { return x !== undefined; } and be done with it. It might annoy my reviewers, though. _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
