What is Boilerplate code, Hot code and Hot spots?

Solution 1:

"Boilerplate" has nothing to do with performance: it just means standard code that is required to define an application or work with some framework. It's code that is likely to be identical in every application.

A "hot spot", on the other hand, means a part of the code that is executed many times and therefore its performance matters a lot to the overall application performance. Usually a hot spot is identified by actual profiling: it's not a hot spot if it's executed many times but is so trivial that its impact on performance is minimal.

Solution 2:

Boilerplate code

"hot code" is scalable well written code

"hot spots" are an area of intense activity. They're hot spots because they're frequently executed code.

Solution 3:

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<CPtrArray,COperation *>::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<CPtrArray,CJob *>::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<CPtrArray,CTask *>::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<CPtrArray,CTask *>::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.