What is Boilerplate code, Hot code and Hot spots?

Question

I know these terms are used in context of performance achievement/optimization.

Recently have been working on that, and have tried searching; but didn\'t get any e

Answer 1

One definition of "hot spot" is a region of code where the program counter spends a good fraction of its time. A related term is "bottleneck" which, while ill-defined, generally refers to code localized to a function, routine, or method, that causes a higher fraction of time to be spent than necessary.

Both these terms are very misleading, because there is a huge unwritten assumption. The assumption is that there are no opportunities to speed up a program that are not a hotspot or a bottleneck. Speedup opportunities can be more diffuse than that, and if they are not found and fixed, they become the performance limiter.

Let me give an example. Recently, when working on a C++ program of about 300 lines, I took ten stackshots, because I wanted to see how I could speed it up. Four of those stackshots looked like this:

CTypedPtrArray::operator[]() line 1555 + 23 bytes
TcProcess() line 246 + 14 bytes ---> COperation* pOp = oplist[i];
CMhAck::Handler() line 165
doit() line 297 + 12 bytes
main() line 318

CTypedPtrArray::operator[]() line 1555 + 23 bytes
SchProcess() line 212 + 14 bytes ---> pJob = joblist[i];
COpAck::Handler() line 145
doit() line 297 + 12 bytes
main() line 318

CTypedPtrArray::operator[]() line 1555 + 23 bytes
TcProcess() line 249 + 18 bytes ---> pTask = pOp->tasks[pOp->iCurTask];
CMhAck::Handler() line 165
doit() line 297 + 12 bytes
main() line 318

CTypedPtrArray::operator[]() line 1555 + 23 bytes
COperation::~COperation() line 57 + 15 bytes ---> CTask* p = tasks[i];
COperation::`scalar deleting destructor'() + 37 bytes
TcProcess() line 259 + 28 bytes
CTskAck::Handler() line 193
doit() line 297 + 12 bytes
main() line 318

The program took 20 seconds overall. What these stack samples are telling me is roughly 40% of that time, or 8 seconds, is spent in the indexing operator on the array class. That tells me I could reduce running time from 20 seconds to 12 seconds, give or take, if I could do indexing more directly, not through a function call. The speedup would be 20/12 = 1.67, or about a 67% speedup. (Notice: I don't give a hoot about "exact" when it comes to timing. What I wanted to do was find the problem.)

Now one might easily disagree with that method of fixing the problem, but you can see how I detected what the problem was, right?

OK, so where's the "hotspot" and where's the "bottleneck"? Clearly there's a hotspot in the indexing operator function, but is that where the problem is? (Actually it's not even that, because it's three different functions.) Does that mean I should try to make that routine faster? I don't even own it!

Is there a bottleneck in the form of some "slow routine"? No! There's no particular routine that's slow, or a "bad algorithm".

What I did was make a description of what it was doing ("It's indexing in certain routines.") where that description applies a large fraction of the time.

The best term I can come up with for these things is "time drain", because it's spending a large fraction of time doing things that don't really have to be done.

More about terminology and popular misconceptions.