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 example, which clearly elaborate/describe these concepts with the realization of these problems/concepts in real world development scenarios.
Can somebody please thoroughly explain these terms, example scenarios, and where these concepts and terms are likely used.
Thanks.
"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.
"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.
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.
Read Defintion : https://en.wikipedia.org/wiki/Boilerplate_code
handle it by https://projectlombok.org/
My assumption is that you already have sufficient definitions for the term "boilerplate". I would probably wish to back what you have with the help of an example. Coming from a Java background and recently moving to Scala, you realize that in Java, you can't write statements devoid of semicolons (;). Further, it is not unusual to write thousands of statements for a program that's probably running in production. Your guess is as good as mine, you end up writing a lot of repetitive low-impact code but it happens to be code that's demanded by the Java compiler. Scala is a concise language in the sense that the need to write boilerplate code has been reduced. You don't have to write semi-colons in Scala. Hope this is simplistic enough
