Re: How to speed up 'automake'

[Jan Engelhardt]

On Monday 2022-05-02 14:20, Thomas Jahns wrote:
>>>> Is there a way to speed 'automake' up?
>>> 
>>> [...let] ephemeral builds [..] use /dev/shm [...]
>> 
>> There ought to be little difference [...] automake, that's nowhere near as
>> IO-heavy as untarring kernel source archives. It's much more a CPU-bound
>> task.
>
>I found tmpfs to be faster when there were multiple smallish (less than an fs
>block) writes to the same file, particularly by different programs. This may
>be more important in the context of all autotools taken together than automake
>alone. Also not all file systems take full advantage of all methods to prevent
>the system from hitting disk like XFS does, i.e. results depend on what you
>compare to.

But you're just acknowledging that the slowness comes from the _fs_, are you 
not?

Anyway...

Indeed, if a source code package consists of 10000 files, then configure
produces another 10k files for the stuff in the ".deps" directories.
There is not much autotooling can do here, as I believe pregenerating
those 10k files all with "# dummy" content is to support the least common
demoniator of /usr/bin/make.

I wonder, rather than emitting those 8 bytes to .Po/.Plo/.Tpo/etc. files, could
we emit 0 bytes instead? Then filesystems would have to write only the inode
and forego extent allocation for the data portion (and save some disk space
too, as each 8-byte file in practice reserves something like 4K on
non-packing/non-compressing filesystems).