https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> --- > > So it effectively replaces gcov's own buffered I/O by stdio. First I am > > not sure how safe it is (as we had a lot of fun about using malloc) > > Why is not safe? We use filesystem locking for .gcda file. Because user apps may do funny thins with stdio such as they do with malloc. Fewer library stuff we rely on, the less likely we will hit the problems. So I am not sure if simply fixing i/o isn't better approach, but I do not know. > > > also it adds dependency on stdio that is not necessarily good idea for > > embedded targets. Not sure how often it is used there. > > It was motivated by PR97834. Well, I think it's better to rely on a system C > library > as it provides a faster implementation of buffered I/O. > > For embedded targets, I plan to implement hooks that can be used instead of > I/O: > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559342.html > > > > > But why glibc stdio is more effective? Is it because our buffer size of > > 1k is way too small (as it seems juding from the profile that is > > dominated by fread calls rather than open/lock/close)? > > It behaved the same on my machine, but BSD impact was more significant. Clang training seems to be a good extreme testcase and not that hard to set up. It is relatively large testsuite and streaming is clearly dominating over everything. Profile also seems quite clear that read dominates other syscall overhead. > > I'm planning to collect more detailed statistics about why is a lot of small > I/Os slower. >From the perf it seems that simply the syscall overhead plays important role (about 20% at kernel side, plus 9% on glibc side) followed by some stupidness of opensuse setup - apparmor and btrfs. > > In the case of Clang, I would expect 100s (or even 1000s) of object files. > During profiling > run (using all cores), I would expect each run takes 100ms (or even seconds), > so waiting > for a file lock of an object file should not block it much. 2727 gcda files, 44MB overall, 4MB xz compressed tar file. I am actually surprised that the file count is quite small. Firefox has more... Honza > > > To avoid waiting for lock one can simply allow multiple profile files to > > be created and teach libgcov to acquire unlocked file in pseudorandom > > order. > > > > Honza > > -- > You are receiving this mail because: > You reported the bug.
