https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
David Malcolm <dmalcolm at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #19 from David Malcolm <dmalcolm at gcc dot gnu.org> --- (In reply to David Malcolm from comment #11) [...] > Even if we fixed that, this seems to have uncovered an issue with input.c: > if I add some logging to input.c, there seems to be something going badly > wrong with the caching of reading source lines, for this case at least. > > get_next_line is being called many more times that I would have expected > given the pattern of calls to location_get_source_line. For some reason, > the cache isn't working, and it's re-reading large chunks of the source file > each time a diagnostic_show_locus is called (even on repeated calls to > access the same line). Instrumentation results in comment #17 shows that it's not re-reading the file from disk, it's merely doing a lot of rescanning for newlines within the buffer that it's loaded. (gdb) p c->total_lines $22 = 51888 and the line_record shows that, as expected, it's inserting a line_record entry every 519 lines (100th of the total line count, as per fcache_line_record_size). It looks like the cache behavior could be improved. In particular, repeated accesses to the same source line are more expensive that they could be: each time it tries to count forwards from the last line_record entry, rather than reusing the line information it got last time (in input.c:read_line_num). I'll try to fix it.