clj-async-profiler is a sampling profiler. It shows you the distribution of the time spent, not the absolute time values. The number of samples, on the other hand, gives a rough idea of which solution spends more time in absolute numbers, however they are roughly the same in your case. Can you show the full expression that you use to profile?

Regarding the bottleneck, it is most likely caused by destructuring in the lambda, that's where RT.nth calls are coming from. If you know that the elements are vectors, it is much faster to take them apart manually with either (get elem 0) or (elem 0) and so on.

Sure, this is the expression:

(prof/profile (for [x (range 0 4000000)
                        y (range 0 1)
                        :let [found (bbb x y)]
                        :when found]
                    found))

Just in case, wrap for in doall to eliminate the possible laziness shenanigans, and rerun the experiment

oh interesting, removed destructuring and the time went from 10s to 3s

now the same experiment (adding type hint) doesn't change the flamegraph, gt component doesn't disappear like before. Why is that the case?

Did you repeat both measurements (before removing the restructuring) with the doall added? I'm pretty sure that profile doesn't enforce lazy evaluation under the hood, and in that case any measurements may be bogus

If you give me the code for distance function, I'll repeat your measurements and tell you what's going on

wow thanks, this is the code

I actually gone back with the destructuring with doall to understand what was happening, (why is gt being replaced by nth in the graph)

I ran your code with and without the primitive hint, and I get pretty much same flamegraphs. Which says that destructuring absolutely dominates everything else. Diff also shows that the profiling results are close to identical

When destructuring is removed, the version with primitive hint performs slightly faster. It also shows on the diffgraph between two versions (see how gt disappears):

Still, the runtime is dominated by every? which is not very efficient. I would next rewrite it to reduce, that will speed things further.

hm I tried to generate a diff and got this

it might be related to my env. I think I'll leave it for now and retry if it ever happens again. Thank you so much for you time and insight. I didn't know the profiler can be used that way. And the tips are very precious as well.

Related to this I just released a new version of ham-fisted which has an extensible primitive typed let pathway - so you can destructure into primitive doubles or primitive longs - https://cnuernber.github.io/ham-fisted/ham-fisted.hlet.html