https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #3 from Jan Hubicka <hubicka at ucw dot cz> --- > A small improvement can be achieved by the removal of libgcov I/O buffering: > https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=5a17015c096012b9e43a8dd45768a8d5fb3a3aee 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) and also it adds dependency on stdio that is not necessarily good idea for embedded targets. Not sure how often it is used there. 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)? > > But the key thing is likely the ability to omit profile modifications > (read/modify/write) for parts of a binary that are not trained. Problem there are the per-program summaries that needs to be updated even for files never visited. It seems that producing one file with tar-like format that can be expanded to gcda files by gcov-tool would be good idea. Even if we need to lock whole file it is probably faster than a lot of small I/Os. 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
