Re: How to speed up 'automake'

[Thomas Jahns]

> On Apr 30, 2022, at 01:31 , Jan Engelhardt <jengelh@inai.de> wrote:
> 
> On Friday 2022-04-29 22:59, Thomas Jahns wrote:
>> On 4/27/22 3:49 PM, R. Diez wrote:
>>> Is there a way to speed 'automake' up?
>> 
>> While you are probably looking for system-independent advice, the best 
>> results
>> I've had with speeding up ephemeral builds is to simply use /dev/shm for
>> backing storage on Linux, i.e. first try to put build directories there
>> ($XDG_RUNTIME_DIR is also fine on modern Linux). If the installation is not
>> needed later on, you can also put the installation path there.
> 
> There ought to be little difference, both use the page cache, except
> that using tmpfs carries the usual volatility risks (not backed by a
> real device, susceptible to power loss, etc., blocks other serious
> processes from using resources, and tmpfs objects may get moved to
> swapspace, which isn't great at all considering you get to pick up
> pieces from the swap partition in the event of a power loss.)
> 
> tmpfs may be interesting from a psychological point of view and/or
> when there are a *lot* of files. But automake, that's nowhere near as
> IO-heavy as untarring kernel source archives. It's much more
> a CPU-bound task.

Very much depends on what the programs do: 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.

Thomas

smime.p7s
Description: S/MIME cryptographic signature