48

I am writing a document and I have a problem with Emacs' performance that I think appeared just yesterday. I haven't made any alterations in my init file or installed any new packages.

The problem is that while I am writing, there's a very noticeable lag between pressing the letters on the keyboard and having them show up on the screen. Sometimes I watch them still printing on the screen after I have finished typing the word.

I don't know if there are other issues except the speed of typing (I can only guess that there are) but I haven't noticed them.

What can cause this problem?
Is it caused by Emacs or it is due to my pc's performance? Generally what are the variables that affect Emacs' performance?

My Emacs' version is GNU Emacs 24.3.1

The major active mode is:

  1. LaTeX

and the minor active modes are:

  1. Auto-Complete
  2. Auto-Composition
  3. Auto-Compression
  4. Auto-Encryption
  5. Blink-Cursor
  6. File-Name-Shadow
  7. Font-Lock
  8. Global-Auto-Complete
  9. Global-Font-Lock Global-Hl-Line
  10. Line-Number
  11. Mouse-Wheel
  12. Shell-Dirtrack
  13. Show-Paren
  14. Smartparens
  15. Smartparens-Global
  16. Tooltip Transient-Mark
  • 5
    C-h m will reveal major mode and all minor modes that are active. You can slowly disable each minor-mode until you track down the cause. It could be the major mode itself, but the minor modes are the most likely suspects. Without specifying which modes you are using, anyone here would be just stabbing in the dark at what is going on with your issue. I have a rare situation that occurs with some special images -- e.g., when someone e-mails me something with a telephone symbol or other special symbols in the iPhone -- but that is an isolated slow-down issue caused by special symbols. – lawlist Dec 14 '14 at 1:46
  • 2
    linum-mode slows down performance in large buffers. nlinum-mode written by Stefan is better for larger buffers. – lawlist Dec 14 '14 at 18:37
  • What is happening on your computer? How much memory is being used? How active is your cpu and which programs are responsible for most of its use? The problem may well be some other program. – Dave Dec 14 '14 at 18:37
  • 2
    Oh, I just posted this reference in another thread: gnu.org/software/emacs/manual/html_node/elisp/Profiling.html - this would be a good start. Also, a shot in the dark: try disabling font-lock gnu.org/software/emacs/manual/html_node/emacs/Font-Lock.html - this is my first usual suspect (which often justifiably takes up most of the CPU cycles). – wvxvw Dec 14 '14 at 19:40
  • 1
    The sheer number of suggestions in these comments shows that this question is a little too vague. I have reworded the title to ask for instructions, instead of a solution. I've also provided an answer accordingly. Please ask a new question once you have followed those instructions, or leave a comment if they weren't clear. – Malabarba Dec 16 '14 at 12:05
74

What can cause this problem? Is it caused by Emacs or it is due to my pc's performance? Generally what are the variables that affect Emacs' performance?

Emacs has around 50,000 internal variables and a few thousand external packages averaging at a few dozen variables each, you can't expect someone to answer this in a general sense. :-)

You can see that just by looking at the comments thread under your question. There are half a dozen different suggestions in there, all equally valid.

What can you do to pinpoint the problem?

Option 1: Disable modes

Start disabling those minor-modes you've listed, and see which one solves you performance issue. I would start with smartparens, auto-complete, line-number and font-lock, and then follow down the list.

"I didn't have this problem yesterday" means very little, don't rely on it too heavily. Just start disabling minor-modes until something solves it.

If none of the minor-modes fix your issue, then start commenting out portions of your init file until you find out which snippet was causing this. In any case, ask a new question when you have something more specific.

Option 2: The profiler

  1. Invoke M-x profiler-start RET RET (the second RET is to confirm cpu);
  2. Do some typing, preferably an entire paragraph or more;
  3. Invoke M-x profiler-report.

That will give you a buffer describing the cpu time taken by each function. Hitting TAB on a line expands it to display the functions inside it. Navigate this buffer until you find out which function is taking so much CPU time.

What do I do afterwards?

Once you find the function or package or snippet causing lag you can (in no particular order):

  • Ask a new question here regarding that specific minor-mode (or function or snippet).
  • Report a bug to the package maintainer.
    • Check the comments at the top of the package's source file. If it contains a URL (specially on github), there's probably an issue tracker there.
    • Some packages offer a command like M-x PACKAGE-bug-report.
    • His or her email should be at the top of the package's source file.
  • If it's a built-in package, you can report it with M-x report-emacs-bug.
  • Even for packages that are not built-in, you can ask for help at the help-gnu-emacs mailing list.
| improve this answer | |
  • 4
    These are great instructions. Thank you very much! As I have said in the comments of my qusetion I didn't know that it was going to be vague. I thought the answer would be elementary for someone expert on Emacs (like many of you are). Anyway this "guide" is great and I am happy that my question lead to that. :) – Adam Dec 16 '14 at 21:59
  • 3
    +100000 for using the profiler. If you're silly (like me) and accidentally do something like add an expensive function call to the mode line in every buffer, this is for sure the way to figure out what's going on. – Radon Rosborough Dec 12 '16 at 20:31
  • How do u disable minor mode? Enabled minor modes: Async-Bytecomp-Package Auto-Complete Auto-Composition Auto-Compression File-Name-Shadow Flycheck Flyspell Font-Lock Global-Auto-Complete Global-Auto-Revert Global-Eldoc Global-Flycheck Global-Font-Lock Global-Git-Commit Global-Hl-Line Global-Hungry-Delete Global-Linum Line-Number Linum Magit-Auto-Revert Org-Bullets Org-Indent Override-Global Projectile Pyvenv Recentf Save-Place Shell-Dirtrack Show-Paren Show-Smartparens Show-Smartparens-Global Size-Indication Smartparens Smartparens-Global – Stryker Mar 9 '17 at 17:45
2

In addition, there is also a potential factor that will significantly slow down Emacs: Font Configuration.

It may sound amusing, but it really matters. If there are lots of non-Latin characters that can't be found in most fonts (for example, CJK) in your buffer, it will take a long time for Emacs to get the fallback font, thus making it very slow.

If this is the case, making a proper font configuration will be very likely to solve the problem. For example, if you are using Chinese heavily (like me), one lazy solution should be getting a proper font that supports Chinese (such as Sarasa Gothic, whose non-CJK parts are also well-designed) and then make it the default via Options -> Set Default Font... or by putting something like this in your .emacs file:

(custom-set-faces
 '(default ((t (:family "Sarasa Fixed SC" :foundry "outline" :slant normal :weight normal :height 120 :width normal)))))

Since I don't know the details about what kind of script the OP is using, I cannot offer more suggestions. However, this solution is often overlooked!

(PS: When I was using Emacs on Windows for the first time, it was unbearably slow when reading the tutorial in Chinese, even though I hadn't installed any packages. After a proper font configuration, everything went well.)

| improve this answer | |
  • 1
    That can indeed be a significant source of slowdown. I think the slowdown will be different from the one described by the OP, but I may be wrong. More importantly, please show some example(s) of what you mean by "proper font configuration" to make your answer more actionable. – Stefan Jul 5 at 15:36
  • 1
    @Stefan I think what the OP described is exactly what I was experiencing. But strangely, I cannot reproduce it now even if I use --no-init-file. However, the symptom was: (1) If the buffer has no CJK characters, nothing is wrong; (2) If the buffer does have CJK characters, the more, the slower. It would even take me a second for something fundamental like C-v to respond! – lhy7889678 Jul 6 at 10:29

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.