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.
