Reduce binary size

[mappu]

The ideas from #8 and #9 can also help to reduce binary size.

Ideas:

• Use -ffunction-sections -fdata-sections in CFLAGS, and -Wl,--gc-sections in LDFLAGS to allow stronger dead code elimination across language boundaries
  • Proposal: Improve dead code ilimination when using CGO golang/go#38135
  • This causes each function to have segment alignment. If a large proportion of the Miqt C ABI functions are used, all the extra padding in the binary could create a net negative effect. Only section alignment, not segment alignment.
• Attempt to build with gccgo
  • Some reports online that this can produce a significant size reduction (although with adding external dynamic dependencies)
• Refactor marshaling code to call helper functions instead of inlining it in every function wrapper
• Ability to disable unwanted Qt classes at compile time?
  • Maybe with a build tag
  • Similar idea to qtminimal
• Ability to disable subclassing support for unneeded classes?
  • The comment in Support subclassing #42 (comment) shows that subclassing support did increase the binary size noticably

[ddkwork]

It's 17-21mb after removing cgo, compilation speed and binary size are very impressive, but I'm not very familiar with cpp classes and templates. I will continue to remove cgo when I have enough experience, I tried to manually fix the c abi file generated by miqt and compiled it to dynamic dll, it was 17mb, the outer code of the go project was about 2-3mb, it added up to about 20mb, on par with flutter.

However, the main repository needs to carry a lot of c abi dynamic libraries resulting in a larger repository, this is another success story

https://github.com/richardwilkes/unison/tree/main/internal%2Fskia

[arnetheduck]

FWIW in the nim bindings, -flto removes almost all overhead since it ends up including only the wrappers that actually get used - this approach of course depends on the underlying C++ compiler - in a way, it's similar to sections but more powerful.

Another idea might be to follow the upstream modules more closely - ie miqt lumps together QtCore/widgets/etc which might not be necessary for all applications - recycling the upstream qt module organisation has other benefits too since the bindings will be more in tune with available documentation etc.

[mappu]

I recall trying -flto, but the Go compiler doesn't do anything with it, so it had no effect overall. It would probably work very well with gccgo or gollvm/llgo. I'll try that, it could be a recommendation for people to make smaller release builds with a different compiler.

There is probably only limited use cases for using a language binding of Qt Core without gui/widgets. Almost everything in Core has some sort of native equivalent in Go anyway. I can maybe imagine extending Miqt to bind some custom library that uses Core types without gui/widgets, but that's hypothetical at this stage. (I'm not sure if Qml or Quick depend on Gui.)

There are also some difficult circular dependencies in the Qt headers between package types - at least QtMultimedia and QtMultimediaWidgets, etc.

[mappu]

• gccgo does not yet implement go 1.18 language features
• TinyGo is an independent LLVM-based Go compiler, that could be capable of dead code elimination across Go/C/C++ boundaries. So far, it is missing some CGO features cgo: invalid #cgo line: CXXFLAGS, pkg-config tinygo-org/tinygo#4765