A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00789.html below:

Re: State of the overlay tree branch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Stefan Monnier Subject: Re: State of the overlay tree branch? Date: Sun, 25 Mar 2018 13:35:07 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) 
> Agree with B1, but not with B2.  Unless I'm overlooking something,
> when the newline cache is disabled, we use memchr, which can search a
> contiguous sequence of bytes in a loop, without translating
> byte-to-character positions.  It only needs this translation at the
> beginning of search, after hitting the gap, and when the search is
> completed.

Hmm... indeed, when the newline cache is completely disabled the problem should
not appear.

>> The patch below tweaks my previous patch to take this into account.
>> The result is now that my test cases stay fast (mostly unaffected by the
>> number of markers) even for large buffers with a large number of markers.
> This is a good change, I think.  But it emphasizes even more the fact
> that if we instead expose to Lisp display_count_lines, which is
> basically a stripped-down version of find_newline with all the
> unnecessary ballast removed, we will get an even better performance in
> applications that need to count lines a lot.

Yes, fixing A is definitely worthwhile.


        Stefan

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