Jan 16, 2025

Oh, ha

Do you have an suggestions for scopes to add to the profiler? The tutorial suggests a function that gets called 100 million times

turns out this function is not that interesting heh

slightly more interesting

Many things get called billions of times. But that’s prob not even the issue, since cpu utilization is very low.

Right, the tutorial just treats something being called 100M times as an "achievement"

The tutorial seems very thorough

Next step is just to figure out where it’s spending 90% of its time. I would expect it to be idling somewhere, since CPU, SSD, RAM, and network are all very low utilization.

Idling might imply heavy lock contention, though I can’t imagine how that is the case. It’s doesn’t deadlock and there does not appear to be an issue of thread starvation. But the performance behavior is similar to what I would expect if it was running on a single (or few) thread.

The network thread count is determined by config alone, which is pretty simple. One thing I do in visual studio is to pause in the debugger and look at the graphical presentation of call stacks by thread. Most threads should be in some aspect of block parse or block check. If most are idling in the threadpool this would point to the problem.

This looks like a list of threads. If so it seems that they are very closely synchronized.

which functions should i instrument for "block parse" and "block check"?

I don’t see that as a productive path. There are thousands of functions and none that will cause a delay like this. If they were causing the delay they would show very high cpu because they are single thread functions.

The most costly of them are the hash accumulation invoked from bc::network::message::block::deserialize and validation in bc::system::chain::block.check() and block.check(ctx)