[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Degenerate file access patterns
From: |
Han-Wen Nienhuys |
Subject: |
Re: Degenerate file access patterns |
Date: |
Tue, 21 Mar 2017 01:21:11 +0100 |
On Thu, Mar 16, 2017 at 9:36 PM, Trevor <address@hidden> wrote:
> I'm trying to run LilyPond in Google Cloud Functions
> <https://cloud.google.com/functions/>, and execution is ridiculously slow
> (like 40 seconds compilation vs. 2 seconds on my laptop). A Google Cloud
> engineer tested it and reported the following:
>
> "The culprit is that the lilypond binary has a bit sub-optimal file access
> pattern (opening the same file thousands of times and reading it byte by
> byte, causing a syscall flood - nearly 500K lseek and read operations). On
> a local machine, because of this issue, it will spend about 1s in I/O
> syscalls, which is half of the total execution time. This currently does
> not play nice with our systems, getting it from 1s to over half a minute."
>
> Anybody know why this behavior is exhibited? Is this something that might
> be within the power of a programmer new to LilyPond development to fix?
The font support is reading the same section of some font file over
and over again.
$ cat f.ly
{ c }
$ strace -e trace=open,read lilypond f.ly >& log ; grep OTTO log|wc
992 5953 90234
$ grep OTTO log|head -10
read(6, "OTTO\0\r\0\200\0\3\0PCFF
\364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
read(6, "OTTO\0\r\0\200\0\3\0PCFF
\364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
read(6, "OTTO\0\r\0\200\0\3\0PCFF
\364\24\241\262\0\0\t\334\0\0\373PFFTM"..., 4096) = 4096
the number of calls is apparently proportional to the number of glyphs
in the file:
$ cat f.ly
\repeat unfold 100 { c }
$ strace -e trace=open,read lilypond f.ly >& log ; grep OTTO log|wc
40929 245575 3724501
Werner may have better hunches than I which code is really responsible for this.
--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen