Menu
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.
278
In computer programming, boilerplate code, or simply boilerplate, are sections of code that are repeated in multiple places with little to no variation. When using languages that are considered verbose, the programmer must write a lot of boilerplate code to accomplish only minor functionality.
Hot code (or hot code path) are execution paths in your application / compiler in which most of the execution time is spent, and thus which are potentially executed very often.
Boilerplate isn't just a code per se, it's a set of instruments (including code). This is a ready-to-use Android template that The APP Solutions company app developers use as a foundation for new Android projects (based on Java, not Kotlin Android).
For example, the Getter/Setter in the JavaBean model class is a boilerplate code. We can reduce such boilerplate code by using the @Getter/@Setter annotation of Lombok. Original code: public class User { private Long id; ... public Long getId() { return id; } public void setId(Long id) { this.id = id; } ... }
"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.
107
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.
31
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.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
