On Mon, Mar 2, 2020 at 12:01 AM Robert Engels <reng...@ix.netcom.com> wrote:
> Any decent compiler should in-line these private function calls in all > cases - so no function call overhead. > FTR, while I agree that any compiler *can* inline them, I wouldn't feel confident to make as broad an assertion as this - unless I was also prepared to admit that gc does not qualify as a "decent" compiler :) Inlining decisions aren't trivial and I can very well imagine that the way the heuristic is coded today, it wouldn't inline here (in particular, if the individual steps are large). That's why I said that IMO the cost of implementing this change should be weighed against the cost of improving that heuristic, FWIW. If runtime efficiency was the only reason to do the change. I don't believe it would come out ahead in that comparison, but we should still be willing to be surprised there :) > > Give me a system with lots of small easily tested and documented methods > over one with 1000 line methods any day. > > On Mar 1, 2020, at 4:48 PM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > > > > On Sun, Mar 1, 2020 at 11:35 PM Warren Stephens < > wsteph...@prognoshealth.com> wrote: > >> Axel, >> >> I like your example. Var *e* would get re-declared -- so that is a >> change. However, var *x* is not visible past the *with* statement -- >> only var *a* is brought forward. >> >> So we need another attempt at breaking this. :-) >> > > Careless of me. Add `x` to the `with` statement. > > >> Splitting the code into separate funcs introduces calls, and I work with >> big data, many billions of records. So that introduces production >> inefficiency for the purpose of test writing -- which costs time and money >> in the cloud. >> > > Note that you are very much not alone with this. For example, I have > worked on systems with trillions of records. Many on this list - and in > particular, on the Go team - are in very similar boats. I don't say this to > brag - but just to clarify, that a lack of experience with scale is not > generally what informs opinions here. > > I don't really think your suggestion is a priori more efficient, FWIW. > There is no reason the compiler actually *has* to insert function calls, > and given that your suggestion is semantically equivalent to splitting the > code into multiple functions (and that is the most likely way it would be > implemented - after all, with the GC, defer and other features, you can't > just jmp into the middle of a function anyway), I feel it's hard to justify > why it would be more efficient without actually looking at a finished > implementation (and weighing that against putting that effort into better > compiler-optimizations). > > In any case - I don't think efficiency can or should really drive the > discussion. > > >> >> Warren >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/d55e9c5d-6d07-4c91-92c6-a3c3060790bf%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/d55e9c5d-6d07-4c91-92c6-a3c3060790bf%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfERV6e5QLd5i42SUQqhE%3D7a229o2%2BYyMxiQOJ1vhxp%2B1Q%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfERV6e5QLd5i42SUQqhE%3D7a229o2%2BYyMxiQOJ1vhxp%2B1Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEuiSCcFgwofLrsSVQZHPHQ%3D0d7WhnaVbrHVTD2%2BSuBKg%40mail.gmail.com.
