please add orEqual operator

Tue Aug 11 00:36:34 UTC 2015

I'm talking about cases where a failure to inline one function led to an
order of magnitude performance loss.  As a general rule, I only inline
functions when I can demonstrate a measurable and significant performance
gain, for the reasons you listed.  My point is just that you shouldn't
trust automatic optimization heuristics.

On Aug 10, 2015 10:41 AM, "Caitlin Potter" <caitpotter88 at gmail.com> wrote:

> > I've had to track down vendor keywords to force C/C++ compilers to
> inline functions
> > more than once, after the idiot thing's optimizers failed to do so, not
> even when I was
> > using the inline keyword
>
> Off topic, but remember that inlining isn’t always an optimization, and
> the compiler’s heuristics may actually be improving the performance of your
> build when it makes this choice! Of course they can still get it wrong,
> but..
>
> It can be tricky for a method to do as good a job as a compiler could do,
> when optimizing this — for instance, a compiler may be able to eliminate
> redundant or unused tests entirely. A compiler can in some cases have
> static knowledge of the types of values it’s operating on, and save time
> accessing properties or invoking methods. A.p.includes will be O(n) in
> general, and there’s little the compiler can do to improve the algorithm.
> Beyond algorithmic improvements, you aren’t likely to see much optimization
> in the runtime function. But it probably doesn’t matter 99% of the time
> anyways, you probably aren’t going to rewrite a 1-liner into a huge switch
> statement or unreadable set of ternary expressions just to avoid that cost.
>
> I’m quite sure someone will point out how wrong I am on any or all of the
> above points any moment now, I can’t wait =)
>
> On Aug 10, 2015, at 1:15 PM, joe <joeedh at gmail.com> wrote:
>
> I actually like `[1, 2, 3, 4, 5, 6].contains(a)` better, too.  The
> question is, will engines actually optimize it.  I have to admit, I don't
> trust people who say VMs or compilers will do the optimizing for you.  I've
> had to track down vendor keywords to force C/C++ compilers to inline
> functions more than once, after the idiot thing's optimizers failed to do
> so, not even when I was using the inline keyword (which is an optimization
> hint, not an imperative).
>
> I have never had this happen with only one compiler, either; if gcc won't
> inline a function, msvc won't either.
>
> Instead of saying "the VMs probably will. . ." perhaps the TC39 committee
> should *mandate* that they do so formally, in the spec.  Then people like
> me could stop violating bits of the standard that aren't workable with how
> today's VMs work, like the return value of .next methods in iterators.
>
> Joe
>
>
> On Mon, Aug 10, 2015 at 9:52 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>>
>>
>> On Mon, Aug 10, 2015 at 5:42 PM, joe <joeedh at gmail.com> wrote:
>>
>>> Isn't this what switch statements are for?  Perhaps a condensed operator
>>> version of a switch would be useful?
>>>
>>>     if (a == 0 : 1 : 2) {
>>>     }
>>>
>>
>> switch does eqeqeq comparison so is not exactly the same
>> `switch(1) { case true: console.log('never'); }`
>>
>>
>>
>>>
>>> Or perhaps something similar to the set version, but without the set:
>>>
>>>     if (a of 1, 2, 3, 4, 5, 6) {
>>>     }
>>>
>>
>>
>> an `if/of` doesn't feel that right to me ... weird semantic
>>
>> `[1, 2, 3, 4, 5, 6].contains(a)` looks better ?
>>
>>
>>
>>
>>>
>>> One could do this as a standard lib variadic function, I suppose:
>>>
>>>     if (select(a, 1, 2, 3, 4, 5, 6)) {
>>>     }
>>>
>>>
>> No, the main  point of having operators is that the engine could just
>> skip the fallback part.
>>
>>
>> `var a = 1 || doSomethingComplex(123)`
>>
>> as example, will never execute doSomethingComplex whilc passing any value
>> as argument should be already resolved as value.
>>
>>
>>
>> In any case, FWIW, I think this is a classic "nostalgia operator" asked
>> from someone that uses from another PL or just started using JS ... I
>> wouldn't mind some well integrated and well thought shortcut, but I feel
>> like this should be the least priority for ES.next
>>
>> Best Regards
>>
>>
>>
>>
>>
>>>
>>> Cheers,
>>> Joe
>>>
>>> On Mon, Aug 10, 2015 at 6:09 AM, <myemailum14 at gmail.com> wrote:
>>>
>>>> Thanks I'll be searching through archive, and yea i think this is
>>>> something very simple and yet innovative.
>>>>
>>>> On Mon, Aug 10, 2015 at 3:55 AM, Peter van der Zee <ecma at qfox.nl>
>>>> wrote:
>>>>
>>>>> On Mon, Aug 10, 2015 at 3:50 AM,  <myemailum14 at gmail.com> wrote:
>>>>> > Isn't
>>>>> > prop ||= 0;
>>>>> > better than
>>>>> > prop = prop || 0;
>>>>> > and it can be even defined like this.
>>>>> > prop ||= var1 ||= var2 ||= 0;
>>>>> > but then i dont know how we can use it ike this
>>>>> > if (num == 3 ||=4 ||=6)
>>>>>
>>>>> Sounds like you want two operators; `||=` for the compound assignment
>>>>> case and `||==` and `||===` for the "compare the RHS to the LHS of the
>>>>> last `===` or `==` op", or something like that. Defining a single op
>>>>> for both of these cases is likely to lead to ambiguity.
>>>>>
>>>>> The `||=` (and `&&=`) case has been discussed a couple of times, look
>>>>> in the esdiscuss archives.
>>>>> I'm sure something like `||==` has been discussed too though I don't
>>>>> recall it myself. I tend to use switches myself for this in case perf
>>>>> is an issue.
>>>>>
>>>>> - peter
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150810/8815c292/attachment.html>