我想用C ++编写一个dll插件。我可以访问源(作者/ mantainer)并可以修改它们(如果需要进行检测)。 我没有的是调用dll的主机程序的源/符号/等。我只有构建插件所需的标题。 根据客户的行动调用dll。
进行分析代码的最佳方法是什么?围绕dll“包装”可执行文件是不现实的,因为在插件中我从主机调用一些函数并且我需要对这些路径进行分析,所以包装器会使性能产生偏差。
在Kieren Johnston的评论之后编辑:理想情况下我想挂钩到加载的dll就像调试器能够(附加到正在运行的主机进程并根据需要在dll中的某处放置断点) )。可能吗?如果没有,我将需要问另一个问题,问为什么: - )
我使用的是Visual Studio 2010的TFS版本。
为AIX下的同一任务提供建议/答案的奖励点(啊,多个环境的乐趣!)。
答案 0 :(得分:4)
虽然有点烦人,但这是可能的。
在此期间,请保持插件解决方案的加载,VS应自动找到插件的符号。
答案 1 :(得分:1)
不确定VS10,但在较旧版本中,通过指定运行它的exe来调试dll。
让我们将问题分成两部分:1)找出你可能称之为“瓶颈”的东西,2)通过修复每一个来测量你得到的整体加速。
(2)很容易,对吗?你只需要一个外部计时器。
离开(1)。如果你像大多数人一样,你认为如果没有程序各部分的某种精确计时,就找不到“瓶颈”。 不是这样,因为大多数时候你需要修复以获得最大加速的东西不是你可以检测到的东西。 它们不一定是糟糕的算法,也不一定是慢功能或热点。 它们是通过完美无瑕的精心设计的代码完成的分布式事务,如果以不同的方式编码,恰好会出现巨大的加速机会。
Here's an example其中编写得相当好的程序的执行时间从48秒减少到20,17,13,10,7,4,2.1,最后是1.1,超过8次迭代。** 这是一个超过40倍的复合加速因子。 你可以获得的加速因子在每个不同的程序中都是不同的 - 有些可以得到更少,有些可以得到更多,这取决于它们最接近最佳的程度。 如何做到这一点并不神秘。 方法是random pausing。 (它可以替代使用分析器。分析器可以测量各种事物,并为您提供各种可能有用或可能没有用的线索,但它们无法可靠地告诉您问题所在。)
**每次迭代实现的加速因子为2.38,1.18,1.31,1.30,1.43,1.75,1.90,1.91。另一种说法是每次迭代减少的时间百分比:58%,15%,24%,23%,30%,43%,48%,48%。我从探查器粉丝那里得到了很多困难,因为这种方法非常简单,但他们从不谈论加速结果。 (也许这会改变。)