Martin Gregorie  writes:
> The Natural Philosopher wrote:
>> Program loading is my bugaboo. Thats pretty sequential
>
> There's a fair amount of random access involved in converting a file name
> to the disk address of the first data block: ~/project/bin/myprog
> involves three directory lookups (find 'project' in ~. find 'bin' in
> myproject, find 'myprog' in bin - and all involve an access to the
> directory's inode plus reading at least one block in the directory.
> Followed by finding 'myprog's inode and then reading the first block of
> the program - thats roughly two random reads per directory and another
> two to get the first block holding your program.

Almost always cached except for the executable read itself (assuming
it’s not an executable that’s been invokved recently).

Also you forgot the runtime linker (also usually cached).

> Even then there's no guarantee that a non-trivial program in
> sequential blocks: that depends on how fragmented the filing system
> is.
>
> Now, if the program uses dynamically linked libraries (very likely for
> Java, and big C programs) you go through the same process again for each
> library that contains support code that the program needs.

Also almost always cached.

>> And linux caches reads pretty well
>
> Exactly so: on this 'ere 8GB laptop, an i5-cased Lenovo T440, the sort of
> stuff I do normally has around a 1 Gb of running code (the OS, its
> services, plus what what I'm doing) and between 1 and 7 GB of file cache.
> I've just been writing/compiling/testing Java and it is showing 1.2 GB of
> running code and 1.15 GB of disk cache. The bigger C compiles I do can
> easily run the cache size up the 7GB, probably due to all the files the
> linker needs to search.
>
> Just how much speed-up Linux file caching provides is easily found:
> reboot the system and then do a large compilation twice.

No need to reboot, use /proc/sys/vm/drop_caches.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05