Closed fasddag closed 8 years ago
Spacemacs shouldn't be slow other than maybe startup. If it is slow it is usually one specific laggy thing and not general cruft.
What kind of slowness are you experiencing? When is it happening?
If you are on develop
, auto-completion
is not part of the stock spacemacs, you have to add the layer explicitly in your dotfile.
For the packages you don't want you can add them to dotspacemacs-excluded-packages
list and spacemacs will ignore them and then uninstall them.
Also, just to answer your specific question, linum
is a package that displays the line numbers of the file you're in :)
I wonder what your performance problem is. Could you be more specific?
I have a general lag after pretty much any input. Which is particularly noticeable after simple commands, like "j", "k" in normal mode and typing, backspace and ctrl+w in insert mode. This is because you expect them to be instant, but they aren't. Also, this delay builds up. So, for example, if I go ctrl+w, ctrl+w... five times it will pause shortly, delete last word, then pause for longer and delete the other four. If I push and hold "j", it will scroll some, then pause and scroll in chunks or not scroll at all if I am in a larger org-mode-file until I release the "j".
("j", "k" performance can be improved by turning off visual-line-mode, the clever word wrap thing. It also much faster when the cursor does not have to move horizontally, for example when scrolling through commented text and cursor stays on the first character in a line. But fast "j", "k" is not essential with all the other movement options.)
You can disable the mode listed in the mode line with circled letter by pressing on SPC t <letter>
where letter corresponds to the circled letter. If you disable auto-completion with SPC t a
is it better ?
"spc t a" did not make a noticeable difference. Seeing how spacemacs-lite is, apparently, not a thing, am I to close this issue?
ps thanks for your help and spacemacs syl20bnr.
This is actually a big deal for me as well. I get considerable hjkl
lag. Any way to profile this? I have all modeline modes disabled.
System specs might help. OS? Emacs version? Where did you get your emacs? Is your computer old?
Also scope statements and testing might help. Does this happen in multiple types of buffer, or just a certain language? What layers do you have installed?
Happens in all buffers, even in fundamental mode. It gets worse over time. When I restart emacs it gets a bit snappier but only for a short while. Killing all buffers doesn't seem to help.
I'm guessing some list is being accumulated and traversed over time and is called on every motion? That's my best guess...
Is the Emacs you are using from Emacs Mac OS X? If so, you should upgrade to Emacs 24.5 since the "stable" version is not so stable. See this issue: https://github.com/syl20bnr/spacemacs/issues/1184
I'm using the version recommended in the docs: https://github.com/syl20bnr/spacemacs#os-x
I wonder whether this has something to do with this issue https://github.com/syl20bnr/spacemacs/issues/1369 The performance issue I experienced was related to a savehist
variable kill-ring
and now it has been removed in develop
branch. Maybe you can give it a try?
I found this issue because I was coming to open a discussion about performance too. General text entry in spacemacs
is noticeably and quite much slower than e.g. SublimeText
. Smooth scrolling is way worse, but I would be happy to just get decently performing text entry at least. Text entry in vim
is also very fast on my machine, its just emacs
that is quite slow seemingly. I know the next thing to do is display a bunch of stats about my machine and plugins I am using, but I can frankly say that I have done very little to tax what is basically a default spacemacs install on a solid machine (same as @jb55 basically). In other words, it doesn't seem to be easy to just fall into the pit of performance by default. Users need to "think" about it?
More generally my concern is whether emacs
is just generally never going to match vim
et al in editing performance. I couldn't care less about startup time for now.
Make sure your Key Repeat
and Delay Until Repeat
are customized to your liking within the "System Preferences" -> "Keyboard"
preferences. Delay Until Repeat
should probably be short
. There still might be something wrong with Emacs, but this global improvement should be double checked.
How slow is slow? I opened a 300MB text file fine in fundamental-mode
. For programming modes, even files with 10-20k lines are non-issue.
@tuhdo These are hard discussions to have accurately. For a quick and dirty test can you open that same file in SublimeText and tell me if you can observe an improvement? Large one?
If you want to open large file, be sure to disable smooth scrolling. It improves performance quite significant.
@rphillips I updated that setting though not related to the performance I am talking about. hjkl
navigation and so on is simply not on par with raw vim
.
disable smooth scrolling
How?
I'd say text entry is indeed considerably slower than in Vim
especially in modes such as orgmode
, though it occurs in all major modes. But the cursor movement speed was quite OK and not that far away from Vim
when I set both Key Repeat
and Delay Until Repeat
to their respective maximum values. Not sure if there's some configuration issue.
I have no problem with Emacs. It scrolls fast, even with that 300MB text file. If you want a prorgramming file to test, SPC h L
then open vhdl-mode.el.gz
. It's 17k elisp lines and I can press C-v
repeatedly to continuously scroll.
My OS is Ubuntu on a 5400 rpm hard drive with a 5 years-old Windows.
How?
Set dotspacemacs-smooth-scrolling
to nil
in your .spacemacs
.
I did see something like this awhile ago, and IIRC installing aspell from homebrew cleared it up for me.
@jasonkuhrt What theme are you using ? On XQuartz on Yosemite I have poor performance with some themes like zenburn and some others, the display is slower in every way with these themes, I don't know why.
Also what build and version of Emacs are your using ? I was impressed by emacs-mac-port
from homebrew which is far more responsive than the stock brew Emacs build under XQuartz.
@jasonkuhrt also do you have any similar performance issue with emacs -nw
?
@syl20bnr indeed emacs-mac-port
seems to perform much better. Text entry speed is quite OK now. Maybe worth mentioning this in the README file or documentation? Otherwise sometimes people like me might get confused and thought the performance issue stems from Spacemacs while it seems that the real problem lies with the Emacs build we chose. Currently there's no listed reason why emacs-mac-port
is recommended over others in README.
@x-ji good point about giving a reason. The real reason though is not just performance, it is better in every conceivable way. Better rendering, better perf, better OSX integration, better scrolling, better stability, ...
@syl20bnr emacs-mac
?
❯ brew search emacs
emacs emacs-mac
emacs-clang-complete-async railwaycat/emacsmacport/emacs-mac
Caskroom/cask/emacs
@jasonkuhrt Indeed emacs-mac
sorry, it has support for spacemacs icon, be sure to check the available options :-) (there is a PR running to add this to the README).
@syl20bnr Themese I have are:
dotspacemacs-themes '(sanityinc-tomorrow-blue
tronesque
fogus
gruvbox
sanityinc-tomorrow-blue
django
dakron
busybee
hickey
dorsey
clues
hc-zenburn
)
I installed emacs-mac
but so far no super-obvious improvement. I'll see how it goes though. I also set dotspacemacs-smooth-scrolling nil
but no major difference so far (actually scrolling appears the same too).
@jasonkuhrt
I installed emacs-mac but so far no super-obvious improvement
Then there is definitely something different in your setup that makes it abnormally slow. Maybe try without a .spacemacs
so you can remove from the equation your settings.
@jasonkuhrt Also might want to inspect your .emacs.d
folder and even nuking it after making a backup... I was given a lot of headache by one rogue cache file in .cache
subfolder which got super large. I remember other people also having similar issues.
Something else people might want to check out on this thread is your file system. At work I've been using Spacemacs on things served over NFS and all sorts of things, even ones that I wouldn't expect to use the file system, are WAY slower. At times it can't even keep up with my typing speed, I have no idea why. I have no problems on fast local files.
Now that my main org file is decently sized, I'm having performance issues as well. I used M-x profiler-start
, typed a bit, and opened the profiler-report. I saw that a big hunk of CPU was being used like this:
...and I could expand further. I don't know what to do with this information in order to improve performance.
i've experienced the same thing as you @trishume w/ vagrant NFS. it's most noticeable when i try to use magit
i was having issues with tramp-mode. turned out to be an issue with projectile. I used a defadvice posted in one of the threads and it seemed to help a lot. try disabling projectile and flycheck to see if that helps any before investigating any further with the issues on projectile project.
Just to put my two cents in, i have noticed Spacemacs being (sometimes/rarely), quite slow, and laggy but its always hard/impossible to pinpoint the issue. Usually this is the case when having to work with a large file (> 3000 lines)
I have narrowed it down to the font and theme. So anyone having similar issues try to change your font, and theme, my problems are gone with Fira Mono
(DejaVu Sans was slow) and im using some of the soft-* themes, theres dark and light ones available.
And for ultimate speed, turn off font-lock-mode and linum-mode.
+1, @stormpat
The fonts slow my emacs! When I change the font to Fira Mono
, it works well. And then I tried many fonts, such as Courier New
, Menlo
, Monaco
and Microsoft Yahei
, all of them goes slow.
Maybe some modes or the emacs itself are incompatible with some fonts?
It also explains why the spacemacs
is not laggy in CLI mode, no fonts at all!
BTW, here is my environment:
If anyone feels slow in a brand new spacemacs
under OS X, try to change the font to Fira Mono
.
I think continuous benchmarking would be awesome but of course a non-trivial task.
For example on every commit a battery of tests would run such that:
With a report for each git commit on the project it would be practical to track regressions and discover issues. I'm handwaving obviously, the task is comparable to testing every aspect of a a webapp in every device etc. but Something minimal might be practical which would be better than nothing.
For now I'm unsubscribing from this thread as anecdotes mostly make for chasing phantoms. Cheers.
I tried "Fira Mono" as @laohyx suggested. It is much faster. Windows redraw faster (when using golden-ratio), etc. With Fira Mono, all window operations appear to happen instantly, while with "Hack" or "Deja Vu Sans Mono" or "Sourcecode Pro", there is a delay.
Unfortunately, "Fira Mono" is pretty hard for me to read at 10pt.
@synic That is wacky. Seems to make an improvement on Windows as well. Its hard to tell if its just me perceiving differences though. It also might be that the Fira Mono font is taller making less lines appear on the screen. Not sure.
I can confirm that changing the font to "Fira Mono" worked for me too. I'm using a Macbook. Changing themes didn't improve performance perceptibly for me.
I'm also using the emacs-mac-port with smooth scrolling. The scrolling is not yet buttery smooth. But much nicer on the eye after I changed the font. Happiness can come from small things.
Performance regression testing suggested in https://github.com/syl20bnr/spacemacs/issues/1114#issuecomment-136726651 would be very nice, but I don't think it's possible to implement in our current testing infrastructure. See https://github.com/travis-ci/travis-ci/issues/352.
Wow, indeed, switching to Fira Mono makes Spacemacs go faster. On a MacBook Pro.
Is Fira Mono distributed in a different format than SCP?
I am also on a macbook pro, fwiw. Using the recommended emacs build.
I didn't see perceivable difference... Golden ratio window redraws seem to be always instant no matter what font I use. How did you install Fira Mono font? It seems that it has various distribution formats at https://github.com/mozilla/Fira and I installed the otf
format.
Hi, here is the latest progress about font slow problem.
Setting dotspacemacs-mode-line-unicode-symbols
to nil
may solve the problem.
Here is the reason.
We found that changing default font to Fira Mono
fixes the delay. But have you installed the font Fira Mono
? At least I haven't.
If you haven't either, we could discuss the root cause.
But why changing to a non-existed font could solve the delay? In fact, my power line cannot display the powerline's unicode symbols.
So I speculate that drawing unicode symbols make the emacs slow. When I specify the font as Fira Mono
, which doesn't exist, emacs will fall back to Monaco
, in which there is no unicode symbols.
Then I disabled dotspacemacs-mode-line-unicode-symbols
according to the document, making no unicode symbols displayed, and it works.
So the root cause is that drawing powerline's unicode symbols slows emacs in OS X. Please have a try, and disable dotspacemacs-mode-line-unicode-symbols
with any fonts.
@synic @TheBB @swaroopch @myrjola
@laohyx OK so I have always been using vim-powerline
(because of https://github.com/syl20bnr/spacemacs/issues/1012) which does not have unicode symbols displayed at all. Maybe that's why I didn't feel any difference. I doubt whether all the other people really didn't even install Fira Mono when they specified it as the font though.
@laohyx I have Fira Mono installed and I do have Unicode symbols displayed, and Spacemacs is faster for me than the default Spacemacs font.
This must be a common question, but I could not find an answer: how do I improve spacemacs performance?
I suspect I do not need or use most of the functionality, because I do not know about it. Things like auto-completion, line-highlight, linum (whatever that is), smooth scrolling, spell check? In fact, I'd give up things that are useful just to speed things up.
Perhaps, someone could share their init file with all the fancy things disabled?