Что такое код Boilerplate, горячий код и горячие точки?

Question

Я знаю, что эти термины используются в контексте достижения результатов.Сегодня я работаю над этим и пытался узнать об этом из Интернета, но не получил ни одного примера, который бы четко представлял эти концепции с существованием этих проблем / концепций в реальных сценариях развития.Может кто-нибудь, пожалуйста, подробно объясните эти термины, примеры сценариев и где эти понятия и термины, вероятно, используются.

Спасибо.

Answer 1

«Boilerplate» не имеет ничего общего с производительностью: это просто означает стандартный код, который требуется для определения приложения или работы с какой-то платформой. Это код, который, вероятно, будет идентичен в каждом приложении.

«Горячая точка», с другой стороны, означает часть кода, которая выполняется много раз, и, следовательно, ее производительность имеет большое значение для общей производительности приложения. Обычно горячая точка определяется фактическим профилированием: это не горячая точка, если она выполняется много раз, но она настолько тривиальна, что ее влияние на производительность минимально.

Answer 2

Код Boilerplate

"горячий код" - это масштабируемый хорошо написанный код

"горячие точки" - это область интенсивной деятельности.Это горячие точки, потому что они часто исполняют код.

Answer 3

Одним из определений «горячей точки» является область кода, в которой счетчик программы тратит значительную часть своего времени. Связанным термином является «узкое место», которое, хотя и является плохо определенным, обычно относится к коду, локализованному для функции, подпрограммы или метода, что приводит к потере большей доли времени, чем необходимо.

Оба эти термина очень вводят в заблуждение, потому что существует огромное неписанное предположение. Предполагается, что нет возможности ускорить программу, которая не является горячей точкой или узким местом. Возможности ускорения могут быть более рассеянными, и если они не найдены и не исправлены, они ограничивают производительность.

Позвольте мне привести пример. Недавно, работая над программой на C ++ длиной около 300 строк, я взял десять стеков , потому что хотел посмотреть, как я могу ускорить его. Четыре из этих стеков выглядело так:

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%. (Обратите внимание: я не кричу о «точном» времени, когда дело доходит до времени. Что я хотел сделать, это найти проблему .)

Теперь можно легко не согласиться с этим методом решения проблемы, но вы можете видеть, как я обнаружил в чем проблема , верно?

Хорошо, так где же «горячая точка» и «узкое место»? Очевидно, что в функции оператора индексирования есть горячая точка, но в этом ли проблема? (На самом деле это даже не так, потому что это три разные функции.) Означает ли это, что я должен попытаться сделать эту процедуру быстрее? Я даже не владею им!

Есть ли узкое место в виде некой "медленной рутины"? Нет! Там нет какой-то медленной процедуры или «плохого алгоритма».

Я сделал описание того, что он делал («Он индексирует в определенных подпрограммах»), где это описание применяет большую часть времени.

Лучший термин, который я могу придумать для этих вещей, - «утечка времени», потому что он тратит большую часть времени на то, что не нужно делать на самом деле .

Подробнее о терминологии и распространенных заблуждениях.

Answer 4

Я предполагаю, что у вас уже есть достаточные определения для термина "шаблон". Я, вероятно, хотел бы поддержать то, что у вас есть, с помощью примера. Исходя из Java-фона и недавно переехав в Scala, вы понимаете, что в Java нельзя писать операторы без точек с запятой (;). Кроме того, нет ничего необычного в том, чтобы написать тысячи операторов для программы, которая, вероятно, запущена в производство. Ваше предположение так же хорошо, как и мое, вы заканчиваете тем, что пишете много повторяющегося кода с низким уровнем воздействия, но это оказывается кодом, который требуется компилятором Java. Scala является лаконичным языком в том смысле, что необходимость написания стандартного кода была уменьшена. Вам не нужно писать точки с запятой в Scala. Надеюсь, это достаточно упрощенно

Answer 5

Прочитайте определение: https://en.wikipedia.org/wiki/Boilerplate_code
обработайте его https://projectlombok.org/