I'm new to Emacs and I want to use it in work.
I studied helm and helm+projectile tutorials and tried them out.
The version of Emacs I use is 24.3.1.
I used the configuration as described there.
After a couple of minutes of work the popping up of 'helm-M-x' and 'helm-multi-files' buffers becomes too slow (up to five seconds) and the CPU load at that jumps up to 100% according to htop. After restarting of Emacs the problem goes away but only for a short while.
The problem seems not to arise if I dont't call 'helm-projectile-switch-project'.
I really like Emacs now, but this problem makes it impossible to use it. Googling did not give any results, as if I'm the only one experiencing this problem.
Please help
Related
My CPU is oscillating between 20 and 30% usage for CPU usage based on Windows Task manager. it is occurring for several hours now.
I expect this VS Code instance to do nothing.
How can I investigate what is going wrong?
I tried to open "Developer: Toggle Developer Tools", then go to performance tab and record. Unfortunately it is reporting that most of the time is in "idle" (which is what I would expect)
(I also tried to ask on Twitter without success https://twitter.com/apupier/status/1100348567926071296)
regards,
Based on the comments it seems that what the Task Manager reports is the total use of VS both on CPU utilization and memory.
A broad range of reasons could explain the observations you made.
1.Increased CPU and Memory usage by VS Studio.
2. Increased Fan Speed.
3. Your code being idle.
It can be the case that the VS Code or one of its plugins is actually doing something even if you do not actively use it. For sure if it is opened, even without being used the program will use some memory.
You can find more information on the CPU usage per VS Code Extension by typing: code --status in the command line. You can also try to execute: code --disable-extensions to run VS Code without any extensions to see if the CPU/Memory usage is reduced.
Results of the code --status will look like this
There are some related issues you could also see in GitHub, I checked before writing this answer:
100% core CPU usage without apparent reason
Excess CPU usage
Excess CPU usage editing C file
It is usually an extension. E.g. Python Intellisense. It is perhaps outsourcing processing for some scientific project aimed for the good of humanity. Fingers crossed.
Update 2022:
Earlier you could find them easily with VS Codes builtin Process Explorer. Help > "Open Process Explorer."
But the newer versions are very sneaky. They seem to have evolved making them difficult to catch while stealing your cpu. Disclaimer: the behavior may very well be even an unintentional glitch although it does not appear so.
Can you catch it in action?
Its as tough as catching a fly. As of Feb 2022, the moment you attempt to probe into the cpu usage either via vs code "help/Open Process Explorer" OR sometimes even win task manager, it stops/vanishes like a fly. Then it stays inactive for some hours or a day. You forget about it and get busy coding only to find the fans are going crazy because it has sneaked in to be active again. The newer version of the bug is perhaps programmed as such.
None the less with a lot of patience, you can sometimes catch them. Here is one instance and yet it vanished before i could scroll to catch the name.
VS Code Process manager
Solution:
I don't have a reason to probe it beyond a limit, but a small monitoring script should be able to catch the culprit.
Personally, I just had to remove the "Python extension for Visual Studio Code (Python IntelliSense - Pylance)" and that was enough to resolve.
IDE's a notoriously expensive to run. As soon as you open VS Code it loads the program from your hard drive, into RAM; acting as a staging point for all the processes VS Code uses to manage its environment. Things like,
Overhead of the Electron framework upon which it is built
Checking for external file changes that need to be synchronized to the editor
Render pipeline
Child processes to support any extensions you have running
Terminal instances (and by extension anything running in those terminals)
Here's a nifty little extension I found after some quick Googling. It will show you the subprocesses running in VS Code, and may help you identify exactly what is taking up the most bandwidth. Do keep in mind, that by killing some of those processes, you may begin to lose the associated functionality, and indeed possibly even cause VS Code to crash. The only sure-fire way to keep it from taxing your CPU, is to shut it down completely when you're not using it.
Perhaps you could try out another IDE like Sublime, IntelliJ, or Atom and see if they act more as you expect when idle. Personally, I really love the features of Jetbrain's IntelliJ (and similar: Webstorm, PhpStorm, etc).
I got the same problem. It might have something to do with the git operations. You might have DELETED many projects from your current folder, while git didn't register the deletion.
When you do something with the changes, git operations will use a lot of CPU.
The simplest solution is to create a new folder and start running VSCode in it. You can delete the whole old folder, or you can leave it alone. It's up to you.
What I need
a fast/performant way to open any file under a large (git) repo (~9.8k files).
Context
I have tried various solutions, like Textmate.el and find-file-in-repository. I found these solutions via previous SO questions like this and this and through the LocateFilesAnywhere EmacsWiki.
While both solutions work wonderfully for small-to-mdeium repos, in this case they are practically unusable. When I start typing a filename, there's a delay of several seconds before I see any result. And changing any part of the search is very laggy too.
I think the main problem is that on typing any character, emacs/find-file-in-repository starts a shell command (git ls-files...). I really only need to do that when I have stopped typing.
Questions
is there a better library out there for this use-case?
if not, how can I introduce a delay into the command when I'm typing? i.e. while I'm in find-file-in-repository, I want the find-command to be invoked only when I stop typing (let's say a gap of 300ms).
Summary
After I received the three answers I tried them out (also answering my own question as none of the above solutions worked for me). I finally settled for helm-ls-git. Here's a comparison from my point-of-view:
Projectile
took around 30 minutes to index the repo. Since projectile is not aware of .gitignore, the actual number of files is more like 52k.
can be customized but something that just works (i.e. understands git) is preferable
may need to invalidate cache re-index time to time. That would be costly and frequent since new files are added everyday to the repo.
helm-cmd-t
looked good from the description and the source.
hard to install since it's not published in melpa/marmalade etc. More details in this issue I opened up.
GNU Global
Didn't try as it's likely to have the same problems as Projectile (git-unaware, needs it's own "index" that may need to be maintained time to time)
event-jr's answer however opened up some more options: I was unaware of helm till now. Looking at melpa for helm related plugins I found the following:
helm-git
This looked really promising
Was easy to install with package.el since it's in melpa
I also use and love magit - so this looked a good fit.
However, it kept failing with a magit-git-dir: symbol is void kind of error. Did not dive in too much but looks like it needs to be updated. Opened up an issue
helm-ls-git
As the readme says, this is magit independent.
Has been working wonderfully so far. Easy to install (melpa) and is fast.
I use GNU global for this. I have around 20K files in my project. You can run
M-x gtags-find-file and type first few characters. TAB will complete and show all the matching. You can type any characters which is part of the file name and press enter. Will show all the files that contains these characters.
I tried to use projectile for this. But it was way too slow for the 'project indexing'. It didn't complete the indexing even after 1.5 hours and I have to kill it!. Not sure some thing is wrong here. GNU global is much faster and finishes the entire tag creation within 15 min.
You can check out Projectile. It was basically created to provide something similar to C-p, but has a lot of extra project level features as well. First time project indexing will be fairly slow on such a big project, but afterwards Projectile will cache the project files (both on memory and on the hard drive) and subsequent projectile invocations should be nearly instantaneous.
Projectile also has a Helm plugin to display project files and buffers with Helm.
I use helm-cmd-t happily. It will cache the file list in memory. The cache controls are flexible enough for my needs.
I just answered your question about new repo address here:
https://stackoverflow.com/a/8025310/903943
It's https://github.com/lewang/helm-cmd-t
I know this sounds really stupid, but:
I used to compile an Android jni project under Xemacs. The only feature that I needed was the ability to locate the place reported by gcc in the source code, edit and save.
But now this does not work anymore. Probably Xemacs caught some keypresses intended for another window (that is, I did not mention which one has the focus) and switched into a different mode. When I restart Xemacs, it works initially and after a while stops working again.
Question: how do I make it functional again?
What happens when you try this in GNU Emacs? It seems you don't haven't
heavily customized XEmacs so switching shouldn't be painful.
I hope someone with XEmacs expertise can help you, but XEmacs has 13
THIRTEEN followers on Stackoverflow. Clearly your chances of getting help will
improve is you try the Emacs that more people use.
There's an external library I'm working with that frequently pegs my CPU. I'd like to help the author fix it (as I really like the library), but I don't know how to debug the crash properly.
Any tips for debugging Emacs lisp? Bear in mind when it crashes Emacs doesn't work anymore and I have to kill it (so solutions within Emacs itself might not be helpful).
Edit: I should clarify that it is byte-compiled, and this issue doesn't always happen for others, so it may be specific to my architecture/init files. It is definitely related to this library though.
First, always debug the uncompiled version of a Emacs-Lisp program, unless you're convinced the problem is introduced by the byte-compiler.
Second, if the code is hanging Emacs then the code is probably in an infinite loop with inhibit-quit bound non-nil. So the first thing to do is go through the source for the library and change all inhibit-quit references to something else so that C-g will work to stop the looping. After that, load up the library, set debug-on-quit to t and you should get a nice debug trace when you press C-g that shows you where the code is looping. From there, debugging the problem should be as straightforward as debugging any other infinite loop.
I'm not sure how to comprehensively accomplish this.
Currently I build my own bzr Emacs on Windows, so I can see that `display-buffer' now takes a SPECIFIERS option, which could be interesting, but I couldn't find concrete examples of how to use it.
But this problem really has to be solved before display-buffer is called.
For example a Help window previously was visiting Buffer-A, but I've visited Buffer-A in another window while reading the help. Now when I quit the Help window, Buffer-A appears there as well. I want some other useful buffer to appear there.
I have some experimental code that appears to work here.
I emphasize experimental. This could melt your Emacs.
I'd appreciate it if you could contact me on github or here to let me know your experiences with this.
Emacs 24 is not yet released. They have changed the buffer-display/window behavior and Lisp interfaces several times over the release's development period. The current status of the release is pretest, so development is supposedly stopped, except for bug fixes.
However, ongoing emacs-devel#gnu.org discussions show that things are still in flux wrt buffer display and windows.
Your best bet is to check the latest doc and code (which might not correspond exactly, at this point).