Fork me on GitHub

Seems to be a call to find-cljx-source getting the ... path instead of the relative path


Holy Cider, I didn't know we could update project dependencies so easily 🎉🎉👾parrot


Hi everyone simple_smile Is anyone having an issue where when you connect to your app using cider-connect, CPU goes through the roof? I really have no idea what's causing it. I was using an old emacs config with Cider, without any issues – but I've rebuilt it from scratch and now I'm getting this. I think it may have to to with ac-cider...?


@achesnais if you use clj-refactor, that could be it. Cider itself doesn't really do much when you connect.


@macromancer You're saying this gets fixed when you load the file, but how was the variable defined initially?


@malabarba: hm, looks like it could indeed be clj-refactor – is this a known issue?


yep, it's very likely to be clj-refactor – I upgraded it on my old config and it's doing it too now


@achesnais yup. Not really an issue. clj-refactor needs to index quite a few stuff so find usages, rename symbol etc are as fast as possible


You can opt out tho. Customize cljr group and look for defcustoms with "eagerly cache" in their names


Also pls let me know if this is running too long (like more than 5-8mins) and as much as context as u can (project size, environment etc)


@benedek: don’t people get some visual indication that this is happening?


Nope. A msg only if cljr--debug-mode is on


This is not blocking tho but still good point


Hi. I'm writing Clojure tests for Java code. It's not bad, but whenever I do change Java code I have to restart CIDER to use changed classes. Shouldn't that be handled automatically using DynamicClassLoader? Maybe I need to configure something to make it working? Thanks for help.


NVM, I've found C-c C-x that should help.


@benedek: So I did two things: 1) I removed all my Emacs packages and deleted my elpa folder, then proceeded to cider-connect to my project each time with a new dependency. When I readded cljr-refactor, the issues reappeared. 2) I retried to connect but having toggled the debug mode. After 2 minutes the messages buffer printed "Artifact cache updated", but the CPU usage was still there (using an entire core). My project has about 6000 lines of clojure code


in terms of context: I'm using version 2.2.0-SNAPSHOT for both cljr-refactor and refactor-nrepl and running clojure 1.7. I'd be very happy to provide any other info you may need, I confess I don't know that much about Emacs yet so I have no idea what may enter into the picture


I noticed it may have to do with mranderson, based on a sampling from the JMC


you should see something like "AST cache updated" and "macro cache updated" eventually


the above artifact cache is rather using the network to retrieve artifact names and versions


the analyzing of the code uses the cpu


okay – but is it normal that moving from version 2.0 to 2.2 does that?


the macro cache was added in 2.2.0-SNAPSHOT so most likely this is causing the extended high cpu usage


I see – thanks for explaining


you can try (setq cljr-eagerly-cache-macro-occurrences-on-startup nil) in your emacs config


that should stop this behaviour but find usages/rename symbol etc could be slower -- really helpful stuff on a big legacy codebase


yep that solved it thank you so much!


no worries. still this is a trade off. that cpu is busy with indexing stuff for you ;) so really up to you what are your priorities with your project. that said i will look into the macro indexing if there is anything fishy there so any more info you found out while profiling can be useful