当前位置：文江博客话题详情

什么是样板代码、热点代码和热点？

发布于 2024-12-11 23:48:03 字数 159 浏览 0 评论 0原文

我知道这些术语是在性能实现/优化的背景下使用的。

最近一直在研究这个问题，并尝试过搜索；但没有得到任何例子，清楚地阐述/描述这些概念以及在现实世界开发场景中实现这些问题/概念。

有人可以彻底解释这些术语、示例场景以及可能使用这些概念和术语的地方吗？

谢谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一曲琵琶半遮面シ 2024-12-18 23:48:03

“样板文件”与性能无关：它只是意味着定义应用程序或使用某些框架所需的标准代码。每个应用程序中的代码可能都是相同的。

另一方面，“热点”意味着代码中被执行多次的部分，因此其性能对整体应用程序性能非常重要。通常，热点是通过实际分析来识别的：如果执行多次，它就不是热点，但它非常微不足道，对性能的影响很小。

回复收藏 0 原文

断爱 2024-12-18 23:48:03

样板代码

“热点代码”是可扩展的编写良好的代码

“热点”是活动频繁的区域。它们是热点，因为它们是经常执行的代码。

回复收藏 0 原文

坦然微笑 2024-12-18 23:48:03

“热点”的一个定义是程序计数器花费大部分时间的代码区域。
一个相关术语是“瓶颈”，虽然定义不明确，但通常指的是本地化到函数、例程或方法的代码，导致花费的时间比必要的多。

这两个术语都非常具有误导性，因为存在一个巨大的不成文的假设。
假设没有机会加速不是热点或瓶颈的程序。
加速机会可能比这更加分散，如果没有找到并修复它们，它们就会成为性能限制因素。

让我举个例子。
最近，在编写大约 300 行的 C++ 程序时，我花了十行 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% 的加速比。
（注意：当涉及到时间时，我并不关心“精确”。我想做的是找到问题。）

现在，人们可能很容易不同意这种解决问题的方法，但是您可以看到我如何检测问题是什么，对吧？

好吧，那么“热点”在哪里，“瓶颈”在哪里呢？
显然索引运算符函数中有一个热点，但这就是问题所在吗？
（实际上并非如此，因为它是三个不同的函数。）
这是否意味着我应该尝试加快该例程？
我什至不拥有它！

是否存在某种“慢节奏”形式的瓶颈？
不！
没有特定的例程是缓慢的，或者是“糟糕的算法”。

我所做的就是对它正在执行的操作进行描述（“它在某些例程中建立索引。”），该描述在大部分时间都适用。

对于这些事情，我能想到的最好的术语是“时间流失”，因为它花费了很大一部分时间去做实际上不需要做的事情。

详细了解术语和流行的误解。

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.

回复收藏 0 原文

你是年少的欢喜 2024-12-18 23:48:03

阅读定义：https://en.wikipedia.org/wiki/Boilerplate_code
通过 https://projectlombok.org/ 处理它

回复收藏 0 原文

野侃 2024-12-18 23:48:03

我的假设是您已经对术语“样板”有了足够的定义。我可能希望通过一个例子来支持你所拥有的。
来自 Java 背景，最近转向 Scala，您意识到在 Java 中，您无法编写没有分号 (;) 的语句。此外，为可能在生产中运行的程序编写数千条语句并不罕见。您的猜测和我的一样好，您最终编写了大量重复的低影响代码，但它恰好是 Java 编译器所需的代码。 Scala 是一种简洁的语言，因为它减少了编写样板代码的需要。在 Scala 中您不必编写分号。希望这足够简单

回复收藏 0 原文

~没有更多了~