I'm trying to debug a performance problem that seems like a combination of core.async, threads and deref.

I have (core.async/thread ...) that processes work it receives via a channel and send the result back via a separate channel. It has a thread-local atom to preserve state. When I reset! that atom, it's very slow and visual VM shows about 25% of the total time spent in the app is in

clojure.core$promise$reify__7005.deref()

When I comment out the reset! the performance issues go away.

Well, it improves significantly.

I also have a few hundred async-thread-macro-### threads in Visual VM.

sounds like the code that runs async/thread might be starting up more times than you thought?

spending your time in promise$reify.deref means that some lib you use waits on a result in one thread and delivers in the other - looking at more of the call stack should figure out what you are actually waiting on

@noisesmith Thanks for your help. It looks like one of my components was starting a thread and not exiting properly on "stop". Each restart (via reloaded repl) was making more and more threads.

After more investigation of the call stack, almost all of those promise deref calls are for alts!! with a data channel and a timeout channel

That makes me wonder if there is a better way to timeout waiting on a channel.

The java.util.concurrent.CountDownLatch.await() is taking up about 16% of the application time.

Well, the deref on the promise wrapped around that.

when I'm profiling I count anything that is an intentional wait, whether that's sleeping or waiting on a contdown for a timer, as a non-issue

I see there is a "Self Time" and a "Self Time (CPU)"

because assumedly as soon as there was real work to do, it would pre-empt my waiting (if I'm doing it right at all)

The "Self Time (CPU)" is 0.

(This is Visual VM.)

What you're saying totally makes sense.

yeah, that shouldn't be hurting anything -- that said it is possible to construct things with core.async and other buffering / queueing mechanisms that hurt performance in ways that are really hard to diagnose when profiling

but spending time sleeping isn't proof that's happening

Ah...I see. Right. Of course it will take a lot of wall clock time for a timeout. That totally makes sense now.

And while I was at it, I did manage the find the thread that's doing all the work and I have schema checking on for all function calls. Turns out that is the bottleneck!

@noisesmith Thanks again for your help. I appreciate it!

:thumbsup: