1

I've noticed that the more frames i have open the slower any one frame becomes. This is a big problem over an exported X session.

Ive noticed that compiling with some X-toolkits (GTK in particualar) activity in one frame will cause updating of all the other frames contents. That is the scroll-bars in all frames flicker & occasionally it appears as though all the text in all frames is being re-rendered, there's a very slight flicker. Eventually the rate buffers can scroll drops to a point where its silly.

So I want to debug what's going on & causing these frames to be redrawn/updated.

With a single buffer frame editing C++ code Emacs is near fluid smooth (4k screen) even with a lot of extensions running, but as I open more frames, the whole editor becomes less responsive, especially if I split some of these frames.

closed as too broad by Drew, DoMiNeLa10 Mar 19 at 17:48

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • This question is too broad for emacs.SE, I think. As @Stefan suggested, this sounds like something to discuss on emacs-devel@gnu.org or in a bug report (M-x report-emacs-bug). – Drew Mar 19 at 2:36
  • While I think it's fine to give out a couple of pointers to help out with finding the culprit, I think the best approach to this question is to close it. Since drawing the frame is done in C, you'll probably want to use some profiler for that, preferably with a build that has debug symbols in it. – DoMiNeLa10 Mar 19 at 17:48
1

Not sure this question will work well in an SX forum, maybe you'd be better off asking this on emacs-devel. You'll probably want to investigate the toolkit part separately (e.g. try a build with Lucid toolkit or even no toolkit at all first).

For the text part, Emacs will often redisplay everything for one reason or another (e.g. a change in a face). To help investigate those problems, you might like to take a look at the following variables redisplay--all-windows-cause and redisplay--mode-lines-cause. They are arrays where each entry correspond to a "cause" and it contains an integer which counts how many times this cause was responsible. You might like to look at src/xdisp.c while investigating this, so as to figure out what each "cause entry" corresponds to (e.g. the entry nb 50 corresponds to those places where windows_or_buffers_changed was assigned the value 50, the other array functions the same but with var update_mode_lines).

Not the answer you're looking for? Browse other questions tagged or ask your own question.