[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs rendering comparisson between emacs23 and emacs26.3
From: |
Alan Mackenzie |
Subject: |
Re: emacs rendering comparisson between emacs23 and emacs26.3 |
Date: |
Wed, 8 Apr 2020 02:09:13 +0000 |
Hello, Dmitry.
On Tue, Apr 07, 2020 at 22:45:25 +0300, Dmitry Gutov wrote:
> Hi Alan,
> On 07.04.2020 20:42, Alan Mackenzie wrote:
> >> Scenarios that are made slower if the file is large are probably caused
> >> by the same architectural decisions that make (find-file "src/xdisp.c")
> >> slow-ish. All those could likely be improved if CC Mode migrated to
> >> using syntax-propertize-function, with its on-demand approach to parsing.
> > Please would you stop saying this. It's not true, and it gets very
> > wearing. The crude syntax-propertize-function mechanism would have to
> > be considerably enhanced before it could support CC Mode's features.
> I will shut up about it now (saying it twice it plenty), but I am pretty
> confident saying that if you manage to migrate to s-p-f, file opening
> time will go down.
I'm sure it would. If file opening time were really a concern, a hybrid
algorithm would perhaps be the best way: apply the text properties first
in a lazy fashion, and thereafter treat them with care, as CC Mode
currently does. But this would merely transfer the start up time to the
time taken in early scrolls forward.
> Performance while typing is likely to improve too, at least when the
> same buffer is not shown in another window, many thousand lines later.
What makes you think this? Anyway, the case you cite has to be handled
well, too.
> It's not a given, but I'd really like to see you try collaborating
> with Stefan. At least for a prototype, to have a better idea of the
> associated performance tradeoffs. He posted a preliminary patch in the
> past, FWIW.
> "Considerable enhancement" can also be a part of that discussion.
The syntax-propertize-function mechanism works by erasing ALL
syntax-table properties after a change point, then reapplying them
lazily. Considering that s-t properties have an overwhelmingly local
effect, this is very wasteful of processor time.
Consider, for example, editing within a large C++ raw string, a common
occurrence. You yourself reported as a bug sluggish performance here in
mid 2016. The cause was erasing too many s-t text properties at a
buffer change. I think we were talking about 1 second per typed
character in the scenario you gave. There are typically lots of these
properties in a raw string, in particular on " characters.
Consider(2) a C++ template: excusing my C++ syntax knowledge, type in
template class foo < bar, baz >= bar>
, perhaps typing in the odd newline inside the template (a common
occurrence), or nesting further templates inside it (also a common
occurrence). Note how the parenthesis text properties are added and
removed as you type. All these modification are necessary, and they are
largely _before_ the point of insertion, not after it.
Splatting all the properties after the point of change would be
unnecessary and wasteful.
> > And even then, it would be unlikely to be faster than the current CC
> > Mode.
> Some scenarios can become slower, that's for sure. But the more common
> ones can get faster. We won't know until we try.
Trying would be a _lot_ of work. How is one to handle the common
example scenarios above? Well, you'd have to enhance the
syntax-propertize-function with a means of determining a start position
for erasing s-t props, and also a stop position. Once you do that,
you're effectively doing what CC Mode currently does, so where's the
speed advantage coming from?
--
Alan Mackenzie (Nuremberg, Germany).
- Re: emacs rendering comparisson between emacs23 and emacs26.3, (continued)
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/05
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/06
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Eli Zaretskii, 2020/04/07
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/07
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Alan Mackenzie, 2020/04/07
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/07
- Re: emacs rendering comparisson between emacs23 and emacs26.3,
Alan Mackenzie <=
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/09
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Alan Mackenzie, 2020/04/12
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/15
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Alan Mackenzie, 2020/04/19
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/19
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/19
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Dmitry Gutov, 2020/04/20
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/20
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Alan Mackenzie, 2020/04/20
- Re: emacs rendering comparisson between emacs23 and emacs26.3, Stefan Monnier, 2020/04/20