https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97834
--- Comment #7 from Roland Illig <roland.illig at gmx dot de> --- (In reply to Nathan Sidwell from comment #5) > you're looking in the wrong place. see gcov_var and GCOV_BLOCK_SIZE. Hmmm, this looks like there is some buffering. But still, in gcov_open, when I comment out the call to setbuf, the gcov-instrumented binary runs 30 times as fast. (In reply to Martin Liška from comment #6) > Can you please explain what's slow? In the ktrace log from comment #4, it's when the gcov-instrumented binary loads an existing gcda file. I wonder why on NetBSD there is no buffering but on Linux there is. Both stdio implementations are so old that I don't expect any bugs in this area anymore. Am I assuming correctly that the gcov_open from gcov-io.c ends up in libgcov.a? At least the source code looks very similar to the binary code, in that there is exactly one call to setbuf. > Second note: doing strace on Linux on the instrumented binary I see: > > openat(AT_FDCWD, "/home/marxin/Programming/testcases/a.gcda", > O_RDWR|O_CREAT, 0666) = 3 > read(3, > "adcge01...", 4096) = 84 > read(3, "", 4012) = 0 Now I'm completely puzzled. gcov_open calls setbuf unconditionally, yet your stdio stream is buffered, with a reasonable buffer size as well. On a Debian unstable, I ran ltrace, and its output looks fine. It calls setbuf, and then fread (buf, 1, 4096, f), where the 4096 matches (1 << 10) * sizeof(gcov_unsigned_t). There's definitely something that I don't understand here. I will investigate further why libgcov.a on NetBSD is so slow. Thank you for your help up to now.
