Simplify nbb-related check

[vemv]

Background

I noticed some time ago that even a cider-connect (which should be very fast) was a touch slower than usual.

Diagnostic

I found out that this piece of code:

cider/cider-connection.el

Lines 356 to 360 in 09d7219

	;; This check is currently basically for nbb.
	;; See `cider-sync-tooling-eval', but it is defined on a higher layer
	(nrepl-dict-get
	(nrepl-sync-request:eval "cljs.core/demunge" (current-buffer) nil 'tooling)
	"value"))

Adds 2 seconds to the cider--connected-handler sequence.

(Those 2s will only be reproducible on a 'cold' JVM - subsequent calls will be faster. However please note that basically all JVMs are cold when you first start them)

Task

Run the check only when it's relevant.

I reckon it might be tricky since it might not be clear in advance whether we're looking at a nbb connection.

[vemv]

Hi @benjamin-asdf!

I noticed this issue and that you gracefully added nbb support to CIDER.

I wonder if you could check it out?

Perhaps it's easy if (cider-runtime) returns 'babashka for nbb connections. Is it the case?

If so, we could only run the check when the runtime is 'babashka - that would probably zap 90% of the problem.

Cheers - V

[vemv]

...while we're there, cljs.core/demunge could become (and (find-ns 'cljs.core) (resolve 'cljs.core/demunge)) - returning values is always at least a fast toucher than throwing exceptions (plus, we make sure we're not hitting anything like an exception-related nrepl middleware)

[benjamin-asdf]

Nice find @vemv See pull request. Turns out we can rely on the describe op (runtime..) instead and shave of those 1-2 seconds for jvm startup!
I fear the penalty is then pushed down to the next first eval call though. Because as you mentionend, only the first takes this long. But I agree having the startup quick is nicer.

This is a 36% improvement on my end!