Decrease build time using C/C++ incomplete types/forward declaration

[GermanAizek]

Dear contributors and maintainers,
I use the source-based distro Gentoo and every system update is a pain to build a huge number packages from sources with waste time, AUR Arch Linux fans agree with me.
This simple change will help both users of source-based distributions and developers, as the build speed is reduced in the Hyperfine single-core build test.

My benchmark on E5-2699v3 (1 core)

Before

gentoo@gentoo:/media/gentoo/437889e5-f1cd-4f29-84a0-605eacc7cd49/GIT/htop/build$ hyperfine --prepare 'make clean' 'make'
Benchmark 1: make
  Time (mean ± σ):     16.677 s ±  0.685 s    [User: 14.516 s, System: 2.204 s]
  Range (min … max):   15.599 s … 17.558 s    10 runs

After

gentoo@gentoo:/media/gentoo/437889e5-f1cd-4f29-84a0-605eacc7cd49/GIT/htop/build$ hyperfine --prepare 'make clean' 'make'
Benchmark 1: make
  Time (mean ± σ):     14.796 s ±  0.325 s    [User: 12.854 s, System: 1.986 s]
  Range (min … max):   14.260 s … 15.365 s    10 runs

Difference compile time: -12%

References about technique:

• https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Incomplete-Types.html
• https://stackoverflow.com/questions/73586567/how-does-forward-declaration-save-compile-time
• https://www.reddit.com/r/cpp/comments/84ewn5/forward_declarations_to_reduce_compiletime/
• https://arne-mertz.de/2018/03/forward-declarations/

[GermanAizek]

Im fixed merge conflicts to master branch.

[Explorer09]

Related: #1460

[GermanAizek]

Related: #1460

Wow cool many thanks for trying to promote this feature too, since building 16 seconds on a single thread is really a lot considering that htop is a small utility on my 72 thread CPU, 72 packages are compiled in parallel.

I'm trying to push forward declarations into many large packages as it helps developers save time and users of source-based distributions.

[GermanAizek]

NetBSD action is dead:

pkgin: Could not fetch https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0/All/pkg_summary.gz: Service Unavailable

Run 'prepare' in VM
  Exec SSH: cd "$GITHUB_WORKSPACE"
  PATH="/usr/pkg/sbin:/usr/pkg/bin:$PATH"
  PKG_PATH="https://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/10.1/All/"
  export PATH PKG_PATH
  /usr/sbin/pkg_add pkgin
  pkgin -y install autoconf automake libtool ncurses pkg-config gmake git
  git config --global --add safe.directory /home/runner/work/htop/htop
  /usr/bin/ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null netbsd sh
  Warning: Permanently added '[127.0.0.1]:10022' (ED25519) to the list of known hosts.
  pkgin-25.10.0: copying /usr/pkg/share/examples/pkgin/repositories.conf.example to /usr/pkg/etc/pkgin/repositories.conf
  pkgin: Could not fetch https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0/All/pkg_summary.gz: Service Unavailable
  processing remote summary (https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0/All)...

[Explorer09]

Related: #1460

Wow cool many thanks for trying to promote this feature too, since building 16 seconds on a single thread is really a lot considering that htop is a small utility on my 72 thread CPU, 72 packages are compiled in parallel.

I'm trying to push forward declarations into many large packages as it helps developers save time and users of source-based distributions.

I'm not promoting it actually. I just provide an info that a forward declaration patch I proposed before was rejected. For reducing compilation time, forward declaration can help. But it seems like the maintainers don't like struct Foo_* scattered around the code for a reason. And thus it becomes a conflict between two requirements.

It might help clean up some readability mess by declarations like typedef struct Foo_ Foo;, but I'm not sure if this works in harmony with IWYU. You would need to test out further.

[BenBE]

In fact IWYU actually tries to stear you towards forward declarations in its default settings, but we decided to avoid them as maintaining these forward declarations introduces additional overhead of maintaining where they need to be kept and where a symbol is actually provided. Thus in order to have a clear single point of declaration the use of forward declarations is avoided when possible. There are some places that use forward declarations, but these are necessitated by the code structure.

That said, the bare struct Foo_ is just plain ugly and much too verbose; and yet another reason not to use these forward declarations unless absolutely necessary.