4-core Mac Mini, 8GB, 256GB SSD. 1.2GB Komodo memory usage, ~10 files open (none over 1000 lines), ‘memory pressure’ is green
So I don’t close my editor often, and after about a week, it gor from acceptable to pretty terrible performance in response to keystrokes, and it routinely beachballs. Ctrl-F takes ~3 whole seconds to bring up the find bar. Responding to clicks in the text editor becomes erratic, anywhere from instant to ~3 seconds.
With typing, I can get a good 15 character lead on it, meanwhile it beachballs occasionally.
Backspacing over text takes absurdly long, and once it gets going, it’ll suck up 98% of the cpu, pause, then resume.
It’s not a bug, but it’s 100% reproducible for me after about a week.
1 Like
Hi there, we are working towards a tentative fix for this for Komodo 11. I recommend for now you simply restart Komodo once per day. Komodo can save and restore your workspace for you either via Preferences > Workspace or via File > Save Workspace and File > Open > Workspace.
You’re not alone with this. Same symptoms happen on Linux too.
2 Likes
I’m seeing a similar problem after using the latest Komodo for just a few hours:
- One CPU is always pegged at near 100%
- Responsiveness to typing is slow
- Searching is slow
Update: the editor seems a tad zippier after a restart. Cpu usage appears unchanged.
CPU usage being high is not normal, please see if the issue reproduces with Help > Troubleshooting > Restart in Safe-mode.
Are you perhaps pointing Komodo at a very large codebase? It could be that it’s scanning through it, you could try to limit the directory depth via Prefs > Code Intelligence > Code Scanning.
Your other issues are likely related to your CPU usage being high, again this is not normal.
Can a definition of “very large” be articulated?
It’s not something that would hold an absolute value, but lets say in the 1000+ language files (ie. files that would give codeintel functionality).
Well the codebases are small. We’re talking not ever more than 15k lines of python.
What I am reporting is that devoid of any activity for some time, Komodo gets crushingly slow. I use Komodo to do server code (But all local files) I’ll switch to doing mobile code (not in in Komodo) for a few days, come back after the weekend, and switch back to the server code, and when I do it’s terribly slow. QtCreator (where I do the the mobile code) does not experience a similar slow down, so it’s not the system AFAIK. I’ll also close chrome (my biggest memory user) and re-open just to make sure it’s not a swap issue (even though I’m on a SSD)
Do you use projects? ie. are you pointing Komodo directly at your project files or is it just looking at your home folder or similar? Komodo works within the scope you set it to, so if it’s aimed at your home folder it will take far more resources than if you point it at a sub-folder.
Do you work with files or package managers besides Python/PIP? eg. if you use NPM (for frontend libs) then your project folder would have a node_modules folder that can be very large in size and also cause Komodo to slow down if it’s set to scan it.
Well as stated, it’s python, so just pip.
I do not use projects.
It is targeting my home directory, I will from now on to limit it to the server code directories being edited.
I don’t have large server code directories. find . | wc -> 915
I will see how it is with just my server code directory and report back. Changing it to just my server code directory already reports a much lower Real Memory Size (88mb) !! That’s 10% of the original!
Yeah scoping Komodo to just the files you care about makes a big difference. We have a bug open to make this more evident through UX (ie. warn users when they point Komod at a large directory structure).
Well, I think a sane approach would be to only scan those directories that are expanded.
I disagree, you don’t want users manually defining what folders should and should not be scanned. No one would bother going through that process.
The expanded folder would indicate what is of active interest.
My thinking was Komodo won’t look in all these build directories because no files from them are open and they are not expanded. Sure maybe scan once to get snapshot and cache, but as for being allocated memory, doesn’t make much sense.
The allocated memory is for more than just codeintel. True there is definitely some optimizations we should do there (such as moving our in-memory cache to sqlite), but that doesn’t help you right now.
I’ve been using Komodo since v7 or 8 and I found v10 unusable for this reason. I’ve switched to Atom it never seems to have an issue, no matter the number of files, size of, or size of codebase.
See if the nightly addresses this issue for you, we pushed a fix related to input delays introduced in Komodo 10
http://downloads.activestate.com/Komodo/nightly/komodoide/latest/
I have it and will report back in a week 
Though I continue to be perplexed at how so many issues make it into production in an editor of such age (perhaps a question that answers itself?) the Komodo team seems to be pretty responsive, which is why I’m holding on to a license. Sure I’d prefer it not to have issues to start with, but as an engineer, I know how hard it is to test code, particularly timing and long-running scenarios.
As long as they remain responsive, I’ll keep using it, filing issues as needed.
Age is part of it. Our development team has also been on the smaller side for a little while, something that’s been remedied for the Komodo 11 dev cycle. I’m confident future releases will be more stable.
