[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of the overlay tree branch?

From: Eli Zaretskii
Subject: Re: State of the overlay tree branch?
Date: Mon, 19 Mar 2018 15:02:51 +0200

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]