lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Long Compile time with version 2.19.44


From: David Wright
Subject: Re: Long Compile time with version 2.19.44
Date: Fri, 8 Jul 2016 08:40:32 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu 07 Jul 2016 at 23:17:26 (-0700), Andrew Bernard wrote:
> 
> A long time UNIX user myself (pre 1970ā€™sā€¦), I follow what you are saying,
> but you may want to explain to ordinary folks what clearing the caches does
> and the command 'echo 3 > /proc/sys/vm/drop_caches ā€˜, especially since the
> OP is on Windows and does not have such nice things available.

OK. The first time you run a program, it has to be loaded into memory
from the disk, along with the various library functions that the
program uses. Once it starts running, the LP source and all its
library calls are similarly loaded. As it runs, any new files created
will have their extents allocated on the disk as they're written.
All in all, a lot of work.

The second time around, much of this work can be avoided because
operating systems don't have to throw away the loaded version of
the program and the buffers containing the LP source files.
Overwriting the output files will also be faster because all the
pointers to the files' locations are already in memory.

How much difference this makes depends on the OS's capabilities.
Linux is very efficient at hanging on to all it can; a common
complaint of new users is that their computer is running out of
memory, which is usually answered with a pointer to
http://www.linuxatemyram.com/

Writing 3 to the pseudofile /proc/sys/vm/drop_caches is linux's
method of instructing the kernel to throw away all the information
that's been cached in memory. (The /proc (likewise /sys) filesystem
is a way of communicating with the OS kernel through reading and
writing what appear to be just ordinary files.)

In the case of the very first run of LP 2.19.44-1, which was
extremely slow, there's also the matter of disk-caching. During
that run, 73 files totalling 1.6MB were stored with names like
~/.lilypond-fonts.cache-2/94f...595-i686-linux.cache-7
(shortening the random part which is a GUID).
Because those files belong to me, the kernel can't throw them
away, so at least the work in generating this cache didn't have
to be repeated.

Windows probably does similar tricks, but less transparently.

Cheers,
David.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]