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" <[email protected]> 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 <[email protected]> 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 < > [email protected]> wrote: > >> >> >> On Mon, Aug 10, 2015 at 5:42 PM, joe <[email protected]> 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, <[email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> On Mon, Aug 10, 2015 at 3:50 AM, <[email protected]> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
