3

Really bizarre issue here; I suspect it's X-related. This may be better suited to the Linux/Unix SE, but I figured there might be more domain-specific expertise here.

Often (but not 100% of the time), if I run Emacs and Chromium (or google-chrome, I'm on Ubuntu) at the same time, then UI updates on Emacs take ages to show. As in, I'll try to scroll around the package menu and it will take 45 seconds to render a few dozen lines worth of scrolling. It seems to go both ways: I'm updating 31 packages in the background as I type this and there's a few seconds of lag between every character I type and the on-screen rendering.

This issue occurs with both emacsclients and stand-alone Emacs sessions. I have 6 cores and I see that only one of them is being used at the moment, which I think must be the cause of the issue. I 'm only at 60% memory usage with almost no swap space being used, so it's not a question of the system being over-taxed.

It looks like the lag spikes correlate with CPU-intensive actions in Emacs. It's almost as if chromium and Emacs have decided to run on the same core and compete for cycles, but I can't imagine why.

I'm on the latest Ubuntu release, via Xubuntu, and I use XMonad as my window manager. I've never had any other pair of programs have this kind of issue. Firefox doesn't cause this problem, I only discovered it recently after switching to Chrome. What's going on here?

|improve this question
  • Can you reproduce it when you run Emacs without your init file? (emacs -Q) What about if you start up Chrome with a different profile instead? – db48x Dec 9 '15 at 5:38
  • @db48x: Yes, the behavior is the same in both of those circumstances (emacs -Q and chromium-browser --temp-profile). Closing one or the other fixes the problem. – Patrick Collins Dec 9 '15 at 6:40
  • Also, perhaps unsurprisingly, the problem isn't present if I run it via emacs -nw. – Patrick Collins Dec 9 '15 at 6:42
  • That is curious. I guess you could try profiling one or the other to find out what's going on. – db48x Dec 9 '15 at 12:58
  • Same problem here, but just noticed that the spotify-client also causes this. – tristan Feb 3 '16 at 0:06
2

Try running "xcompmgr -n &". (See https://michaelheap.com/google-chrome-stealing-focus-repainting-in-xmonad/)

This finally fixed emacs for me, but, ironically, it has slowed google-chrome down in the current session I am in.

|improve this answer
0

This isn't exactly an answer, but it kind of is. I just don't have rep to comment other wise I would.

This happens to me as well, except I do not use xmonad, I use i3wm, but it goes away if I have the chromium window tiled with another window on the same screen. I also experience this with steam/steam games.

Running htop reveals no process utilizing large amounts of CPU. I speculate that the problem is in an thread that typically "waits" synchronously rather than asynchronously somewhere in Emacs.

|improve this answer
-1

use firefox instead. chrome is buggy. besides, keysnail is a great firefox ONLY addon to convert firefox to emacs

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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