> > If I reading this right, calls to get_next_line lead to insertions into > the ring buffer whilst the buffer is empty or the last line in the ring > buffer cache is m_line_num - 1. > > There are a few places where we update m_line_num, but this caching > code doesn't seem to touch those places. Should it? I don't know if > the lack of a reset is an issue, but it's an aspect of the patch that's > a bit hazy to me; sorry.
The idea was that there is only a single cursor for this cache, assuming the main parser algorithm goes linearly through the file. So even if m_line_num changes temporarily for some warning it will eventually go back to where that cursor was. So I didn't bother to refill the cache on these changes. There is a good chance that the changed position hits the cache if it's within its range. If there is an access pattern where this assumption is not true the cache will not work, but the normal anchors still do of course. I will add a comment describing this. > If I'm reading this right, the caching that this adds is only for the > final 256 lines read so far in the file, and lets us use a line offset > relative to the most recent entry to go direct to such a recent line in > the file. Right. -Andi
