100% CPU when closing all nodes

[humitos]

Hi,

I just installed this plugin into my emacs configuration and I'm having an issue when folding (close) all the nodes with origami-close-all-nodes in a python file with more than 500 lines: emacs takes the 100% of the CPU when I move the cursor and everything is slow.

I tried it in other kind and small files and I don't have that problem. Do you know what could be happening?

(I have a lot of other plugins installed in my emacs configuration, are you aware if there is a known incompatibility with someone?)

I had a similar issue with fancy-narrow at https://github.com/Malabarba/fancy-narrow/issues/17. So, maybe is something my-config-specific, but I'm not being able to find it.

Thanks,

[purcell]

Are you using linum, perhaps? It's one package which can slow things down. There's nlinum, which is a faster (but otherwise equivalent) alternative.

[a-hausmann]

I had a similar problem with "large" files (though 2 Mb, 39000+ lines is not large), though I didn't think to look at CPU--it just took forever to do anything. The problem was definitely linum in combination with origami. I removed all the fold markers in my file (1148 of them) and the problem went away (with origami and linum). I commented out linum from config and edited with origami and folding was fine with excellent response time. NOTE: I use linum-relative, which naturally uses linum.

I found in linum-relative documentation that beginning in version 0.6, if one is using Emacs 26.1+, variable "linum-relative-backend" can be set to "display-line-numbers-mode" which is implemented in C for performance.

My results were immediate and drastic. Origami was immediately available upon opening the file in a buffer, no lag time in calculating all the folds, and Emacs general response time was back to normal.

Ergo, if using linum-relative in any way, ensure you're on at least 0.6, and running the latest Emacs (26.1 as of this writing), and use "(setq linum-relative-backend 'display-line-numbers-mode)".

[dscole]

I'm having similar performance issue with origami. I have a c++ file that I don't think is too large (especially compared to @a-hausmann's 39000+ lines files), it is has about 2500 lines and 380 brace pairs (max nesting is probably 6-7 braces deep). There is a top level struct that everything else in the file is nested with in it. To try and isolate the issue I switch to fundamental-mode, to avoid any cc-mode related stuff. I also don't use linum, so @a-hausmann and @purcell suggestions don't really help me much. When I try to recursively fold that struct with origami, everything becomes crazy slow. Just having the {...} anywhere visible in the window makes scrolling really slow. I think it might have something to do with overlay being quite slow, but really sure how to debug it. It's really driving me crazy how unusable origami is in large files (exactly the files for which origami would benefit me most). Any help would be greatly appreciated.

[a-hausmann]

@dscole, I exclusively use 'triple-braces as origami-fold-style. I found that origami sets up a list of beginning/ending points in order to set up the folds; I'd bet the same happens for C/C++. I also found that Origami doesn't well handle unbalanced triple-braces, so am wondering if perhaps there are unbalances braces in your code base somewhere. I constantly picked on one program as an example to work on, and it wasn't until I tried another--and origami worked!--that I found out about the unbalanced triple-braces issue in my code. Also, you may want to check to see if Line-Number is a listed minor mode (C-h m) in your C++ buffers; it can still be active while not displaying lines.