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 ...
Emacs' handling of long lines is not very well optimized. For a number of operations, Emacs has to scan the whole line repeatedly. For example, to display a line, Emacs has to figure out the height of the line, which requires scanning the whole line to find the tallest glyph. Additionally, scanning for bidirectional display eats up a lot of time. You can get ...
Here's my points on reducing emacs-init-time, this does not cover things like using a daemon or the server, it goes without saying that you should rarely ever close emacs.
Don't require packages in your init, if the package doesn't have proper autoload cookies, ensure you set up autoloads on the entry commands. So if the first time you use package ...
The most straightforward options is the built-in benchmark package.
Its usage is remarkably simple:
(benchmark 100 (form (to be evaluated)))
It’s autoloaded, so you don’t even need to require it.
Benchmark is good at overall tests, but if you’re having performance
problems it doesn’t tell you which functions are causing the problem.
If you have the Emacs source code installed, you can find the source code for sort with M-x find-function.
There you can see that sort performs a merge sort. It checks the length of the list, breaks the list into half, sorts the "front" and the "back" parts separately through recursion, and then merges the two.
As for whether your implementation would be ...
so-long.el (Emacs Wiki, GNU ELPA) will help in many situations. It is included by default in Emacs 27+ and available in GNU ELPA for older versions of Emacs (24.4 and later).
This library enables you to configure some simple thresholds to check when visiting a file, beyond which a more performant mode will be used in place of the normal mode, including ...
I did some brief experiments with this using a minified copy of jquery. font-lock-mode and flycheck-mode both contributed to slowness, as did js2-mode, and prettify-symbols-mode. line-number-mode and column-number-mode had minor effect. Once I had turned off all the different modes though the performance was relatively snappy. Use C-h m and start disabling ...
One of the less known features of Emacs is that it has a profiler! Let's assume your file is called foo.org, then you could do this:
After you've done all that Emacs will pop up a buffer with statistics on CPU usage (you can also choose to profile memory or both CPU and memory, when you start the profiler)...
In addition to @Malabara's answer, I tend to use a custom-made with-timer macro to permanently instrument various parts of my code (e.g my init.el file).
The difference is that while benchmark allows to study the performance of a specific bit of code that you instrument, with-timer always gives you the time spent in each instrumented part of the code (...
One of the design choices in package.el was to try and make things "simple". Part of this is that package-initialize searches for all the packages that are installed, then tries to figure out which ones of those should be activated (according to pinning, and recency of versions in case where multiple versions of the same package are available), then loads ...
Whatever your .emacs and its improvements, you also should consider running emacs as a server at your session's opening :
Now, running emacs with
emacsclient -nw -c
or ... (see options) will be much faster
Reading the GitHub discussion thread linked in @wvxvw’s comment, I discovered the variable inhibit-compacting-font-caches. Setting it to non-nil solves the issue:
(setq inhibit-compacting-font-caches t)
Now navigating point is fast. According to the variable’s documentation, inhibiting compacting font caches comes at the expense of more memory usage, which ...
As already answered in the comments, Emacs becoming very slow in its
redisplay for long lines is a well-known
issue. Fixing it
would be very nice, but needs lots of thought to be pulled off
correctly. I have an idea of how it could be accomplished based on
section 6.3 of this
(basically, store visual line information in the current buffer and
I have actually done rather a lot of research on this and fundamentally the problem is that git for windows sucks
This is the upstream bug: https://github.com/git-for-windows/git/issues/596 and it requires somebody to rewrite shell scripts in C so that there is no more command forking. For me, its the interactive rebase that is the real killer (I can kick ...
As you noticed, this basically happens when the redisplay is too slow for some reason. There's not much we can do in the general case (when it's "much too slow") but when it's "just a tad bit too slow" you can try one of those (or both, tho it probably doesn't do anything more than only one of the two):
(setq jit-lock-defer-time 0)
UPDATE http://git.savannah.nongnu.org/cgit/so-long.git/tree/so-long.el is a part of Emacs 27.1!
OLD I usually unroll long lines and indent by tags (like HTML, XML, JSON).
In order to make such operation possible I add:
(setq line-number-display-limit large-file-warning-threshold)
(setq line-number-display-limit-width 200)
(defun my--is-file-large ()
Definitely. You will especially gain if you just want to test char-before or search backward for a literal string. And if you must use looking-back then try to use a LIMIT argument, if possible.
See Emacs bug #17284 for an example.
It turns out that the wildly varying performance was related to garbage collection. Each call to the function would get slower until a garbage collection was run. With stock emacs, gc was run every couple of seconds, but I had a line in my init.el to improve startup time that set gc-cons-threshold to 20 MB, and that meant gc was run much more infrequently, ...
Something that recently popped up on emacs reddit: decrease the number of garbage collection invocations by putting this near the beginning of your init file:
(setq gc-cons-threshold 50000000)
(add-hook 'emacs-startup-hook 'my/set-gc-threshold)
(defun my/set-gc-threshold ()
"Reset `gc-cons-threshold' to its default value."
(setq gc-cons-threshold ...
I expect you'll find that the difference is due to font-lock. When fontification is to be performed on the subset of the file which is visible in the window, it proceeds by first extending the fontification region such that it will include full semantic units. See the font-lock-extend-region-functions code for this. It's common for this to include extending ...
In short — dynamic binding is very slow. Lexical binding is extremely fast at runtime. The fundamental reason is that lexical binding can be resolved at compile time, while dynamic binding cannot.
Consider the following code:
(let ((x 42))
(message "%d" x))
When its compiling the let, the compiler cannot know whether foo will acess the (...
I've looked through documentation but it seems like there's no such option.
Surprising that org does not offer :output buffer option. Maybe this is in the works for future org versions.
... place the output of certain code blocks to a separate buffer...
Here's one way to simulate that functionality: take the output of one source block and stream it ...
I created my own solution for this problem here: https://github.com/rakete/too-long-lines-mode
I was not satisfied with phils solution which switches a buffer with very long lines to fundamental-mode, I wanted a solution that lets me keep syntax highlighting and other major-mode features. So I created a minor-mode that uses overlays to hide most characters ...
The time you spend optimizing your startup time will likely be greater than all the extra time you would have otherwise waited for Emacs to start up.
At the moment I make 25 require calls in my init file so that Flycheck can find spelling errors in my code. My startup time is...
$ time emacs --eval '(save-buffers-kill-terminal)'
The problem you describe about package-initialize taking so much time to load is a well known problem. It is also one of the problems that some emacs frameworks try to solve by loading the autoloads manually.
I see two solutions to your problem.
Write (or extract from a framework) the functionality to set the paths and load the autoloads of the packages ...
1) I have found esup to be a very convenient for Emacs startup profiling.
You just run M-x esup and get back list of all expressions in your init.el sorted by the time they took to execute. You don't need to restart Emacs or add anything special to the config, so narrowing on the slow down suspect becomes much easier.
2) I (use-package :defer t) all the ...
Deploy different versions of Emacs at the same machine (for Emacs plugin development)
If your OS is too old and you are not a super user, install the latest stable Emacs at your $HOME is the only solution.
There is no performance advantage if you compile it by yourself.
I did a couple of tests using Emacs 24.5 with the 32-bit build provided by GNU Emacs and the 64-bit build provided by Emacs-w64 - I thought the 64-bit build would be a little slower due to the larger pointer size but the differences were pretty negligible for ~20 second processes.
Then at Tobias's suggestion, I tested loading an .org file, and the 64-bit ...
Since I've accepted the answer I've been living with that 'have elisp snippet for each report I want' setup for a while.
But then I've came up with the following trick:
There is a way to open org-babel outpupt in a separate buffer with C-o - org-open-at-point is fancy like that. The problem is, the result block is created. But there is also a command org-...