Any decent compiler should in-line these private function calls in all cases - so no function call overhead.
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. > > -- > 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. -- 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/BE7D7644-E94E-49C0-BB9C-F3ADF0F1E736%40ix.netcom.com.
