emacs-devel
[Top][All Lists]
Advanced

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

Re: macOS metal rendering engine in mac port


From: Eli Zaretskii
Subject: Re: macOS metal rendering engine in mac port
Date: Mon, 24 May 2021 22:21:34 +0300

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Mon, 24 May 2021 12:07:44 -0700
> Cc: emacs-devel@gnu.org, Alan Third <alan@idiocy.org>, 
>       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> lface_from_face_name_no_resolve is called 4.5x more often when line
> numbers are enabled and that's enough to make a difference on my
> machine.

But it doesn't make any significant difference on mine.  And that's a
mystery.

> Could you try adding 500 extra (unused) faces and try the comparison
> again? The slowdown scales along with the number of faces, so your
> linux build may just be better optimized for this particular scenario.

No, I want to continue using "emacs -Q", because we cannot even
explain the difference in behavior there.  Making the problem we don't
understand more complex will hardly help us understanding it.

> > If you turn on highlight-regexp mode, and use regexps that match about
> > 2 times on each line, do you also see a similar slowdown in the
> > scrolling benchmark?  For example, highlight two regexps: "^." and
> > ".$".  This should create the same addition of face merges per line as
> > with line numbers, and so the effect should be similar -- if indeed
> > the reason is face merges and not something else.  In my testing,
> > scrolling through xdisp.c with the above 2 regexps highlighted takes
> > just 2% more time than without them, similar to what I see when I turn
> > on line numbers.
> 
> emacs -Q
> No highlights: 5.47s (slower likely because i'm on master now instead
> of Alan's branch)
> With highlights: 9.4s
> 
> So yes, a similar slowdown for me.

So the mystery remains...

Thanks.



reply via email to

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