Drop pointer indirection of app in SingleCommandApp and MultiCommandApp

[dolmen]

When embedding app in SingleCommandApp or MultiCommandApp, drop the unnecessary pointer indirection.

[Rican7]

Hmm, this is interesting... I understand that the SingleCommandApp and MultiCommandApp are already returned (and used as) pointers, and their methods contain pointer receivers, so there's less likely a reason to need the app indirection, but what's the benefit of this exactly?

[dolmen]

The benefit is that memory is allocated in a single block and a single call to the allocator.

Do you need a proof with a benchmark?

[Rican7]

Ooo, I didn't think of that!

I don't need a proof (though it would be really cool for learning), but rather I just wanted to understand the concept before merging.

[Rican7]

I was curious, so I wrote my own benchmark, and you're right!

I wrote the following simple benchmark in lieut_test.go:

func BenchmarkSingleCommandApp(b *testing.B) {
  for i := 0; i < b.N; i++ {
    flagSet := flag.NewFlagSet(testAppInfo.Name, flag.ExitOnError)
    NewSingleCommandApp(testAppInfo, testNoOpExecutor, flagSet, os.Stdout, os.Stderr)
  }
}

Running go test -bench=. -benchmem shows:

Before Your Changes

goos: linux
goarch: amd64
pkg: github.com/Rican7/lieut
cpu: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
BenchmarkSingleCommandApp-12             1615616               741.9 ns/op           680 B/op         10 allocs/op
PASS
ok      github.com/Rican7/lieut 1.966s

After Your Changes

goos: linux
goarch: amd64
pkg: github.com/Rican7/lieut
cpu: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
BenchmarkSingleCommandApp-12             1787079               730.1 ns/op           680 B/op          9 allocs/op
PASS
ok      github.com/Rican7/lieut 2.000s

[Rican7]

Ah, this change also seems to "fix" (make consistent?) the different method receivers, as the method promotion of the embedded methods was based on the indirection.

Before

---

After

Thanks!