Я знаю, что эти термины используются в контексте достижения производительности. В этот день я работаю над этим и пытался узнать об этом из Интернета, но не получил никакого примера, в котором четко представлены эти концепции с наличием этих проблем/концепций в сценариях развития реального мира. Может кто-нибудь, пожалуйста, тщательно объясните эти термины, примеры сценариев и где эти понятия и термины, вероятно, будут использоваться.
Спасибо.
"Boilerplate" не имеет ничего общего с производительностью: это просто стандартный код, который требуется для определения приложения или работы с некоторыми фреймворками. Это код, который, вероятно, будет идентичным в каждом приложении.
"Горячая точка", с другой стороны, означает часть кода, которая выполняется много раз, и поэтому ее производительность имеет большое значение для общей производительности приложения. Обычно горячая точка определяется фактическим профилированием: она не является горячей точкой, если она выполняется много раз, но настолько тривиальна, что ее влияние на производительность минимально.
"горячий код" - это масштабируемый хорошо написанный код
"горячие точки" - это область интенсивной активности. Это горячие точки, потому что они часто исполняются.
Одно определение "горячее пятно" - это область кода, где счетчик программ тратит большую часть своего времени. Связанным термином является "узкое место", которое, хотя и не определено, обычно относится к коду, локализованному в функции, подпрограмме или методе, что заставляет затрачивать большую часть времени, чем необходимо.
Оба эти термина очень вводят в заблуждение, потому что существует огромное неписаное предположение. Предполагается, что нет возможности ускорить программу, которая не является "горячей точкой" или узким местом. Возможности ускорения могут быть более диффузными, чем это, и если они не найдены и не исправлены, они становятся ограничителем производительности.
Позвольте мне привести пример. Недавно, работая над программой на С++ около 300 строк, я взял десять stackshots, потому что хотел посмотреть, как я могу ускорить ее. Четыре из этих stackshots выглядели следующим образом:
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
Программа заняла 20 секунд. Что скажут мне эти образцы стека, примерно 40% того времени, или 8 секунд, расходуется на оператора индексирования в классе массива. Это говорит мне, что я мог бы сократить время работы от 20 секунд до 12 секунд, дать или принять, если бы я мог делать индексацию более напрямую, а не через вызов функции. Ускорение будет 20/12 = 1,67, или около 67% ускорения. (Обратите внимание: я не рассказываю о "точных" моментах, когда речь идет о сроках. Что я хотел сделать, это найти проблему.)
Теперь можно легко не согласиться с тем методом устранения проблемы, но вы можете видеть, как я обнаружил, в чем проблема, не так ли?
ОК, так где "горячая точка" и где "узкое место"? Ясно, что есть горячая точка в операторной функции индексации, но есть ли проблема, где проблема? (На самом деле это даже не то, потому что это три разные функции.) Означает ли это, что я должен попытаться сделать эту рутину быстрее? Я даже не владею им!
Есть ли узкое место в виде некоторой "медленной рутины"? Нет! Там нет особой подпрограммы, которая замедляется или "плохой алгоритм".
То, что я сделал, - это описание того, что он делал ( "Индексирование в определенных процедурах" ), где это описание применяет большую часть времени.
Лучшим термином, который я могу придумать для этих вещей, является "утечка времени", потому что он тратит большую часть времени на то, что действительно не нужно делать.
Чтение Defintion: https://en.wikipedia.org/wiki/Boilerplate_code
обрабатывать его https://projectlombok.org/