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/msg00589.html below:

Re: State of the overlay tree branch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Eli Zaretskii Subject: Re: State of the overlay tree branch? Date: Mon, 19 Mar 2018 14:57:52 +0200
> From: Sebastian Sturm <address@hidden>
> Date: Mon, 19 Mar 2018 10:53:52 +0100
> 
> On 03/19/2018 07:43 AM, Eli Zaretskii wrote:
>  >> From: Sebastian Sturm <address@hidden>
>  >> Date: Mon, 19 Mar 2018 00:20:13 +0100
>  >>
>  >> for the record, I just switched back to emacs master (no noverlay) and
>  >> the time reported by (benchmark-run 1000 (line-number-at-pos (point))
>  >> increased by a factor of ~40, to 75-80s. At this level, editing is
>  >> unbearably slow. With the semantic highlighter disabled, the same
>  >> measurement yields ~2.5s (still painfully slow, but borderline usable),
>  >> so about the same time reported by the noverlay branch.
>  >
>  > You will have to explain why overlays and the semantic highlighter
>  > affect line-counting.  How about presenting a profile produced by
>  > "M-x profiler-report"?
> 
> please find below a profiler report taken this morning (on my PC at 
> work, which doesn't suffer from the performance issue as much as my 2014 
> MacBook Pro, but even here the issue is clearly noticeable)

That profile says that self-insert-command takes a large percentage of
the time.  So I think we should look into the reasons for such a
strange place to spend hundreds of microseconds.  According to the
profile, line-number-at-pos takes about the same percentage of time as
self-insert-command does.  And that is even before you optimize the
successive calls to line-counting code to take advantage of the
previously computed value for some close line.

>  > And the timings you measure are 2.5 _milliseconds_ (the benchmark runs
>  > 1000 times), right?  If so, I cannot understand why you say that's
>  > borderline usable, because IME such short times are imperceptible by
>  > humans.  I guess some other factor is at work here, so I'd suggest to
>  > describe more details about your use case.
> 
> well no, it's about 2.5ms per call to line-number-at-pos, which is 
> called at least 6 times per character insertion (with my Emacs config, 
> at least). Which already makes for 15ms per character insertion, 
> excluding anything else done by cc-mode or lsp-mode.

Then, as I said, I don't understand why it takes so much on your
system.  I get times that are 10 times faster.



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