> From: Stefan Monnier <address@hidden> > Cc: address@hidden > Date: Mon, 19 Mar 2018 08:29:40 -0400 > > > But I don't believe [display_count_lines] could be orders of > > magnitude faster than count-lines, even though it doesn't need to > > convert character position to byte position. > > Scanning from the last used position can be *very* different from > scanning from point-min. So yes, it can be orders of magnitude faster Well, in my measurements it's already very fast. I don't understand why the OP sees times that are 10 times slower. > The > > for (tail = BUF_MARKERS (b); tail; tail = tail->next) > > loop in buf_charpos_to_bytepos and buf_bytepos_to_charpos. > > > But find_newline doesn't look for markers, and it converts character > > to byte position just 2 times. Or am I missing something? > > The idea is that the above loop (even if called only twice) might be > sufficient to make line-number-at-pos take 0.2s. I very much doubt that loop could take such a long time. And running a benchmark 1000 times means that the 2nd through 1000th iteration find the mapping much faster, probably bypassing the loop entirely. > So for them to cause the slow down seen here, we'd need not only > a very large number of markers but also additional conditions that might > not be very likely. > But it's still a possibility. I'll believe it when I see it.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4