想知道stackoverflow社区对各种免费和非免费的Java Profilers和分析工具的看法.
我想使用valgrind进行一些分析,因为它不需要重新构建程序.(我要配置的程序已经使用"-g"构建)
但是valgrind(callgrind)很慢......所以这就是我要做的事情:
我可以在Solaris上使用sun studio来做这种事情.(使用dbx).我只想知道是否可以使用valgrind(callgrind)做同样的事情？
谢谢
我想进一步提高现有Erlang程序的效率.首先,我想确定瓶颈,然后决定进一步优化的位置.
我试过了fprof,但它只提供有关总运行时间和平均运行时间的信息.我最希望看到一个类似于fprof输出的日志,但是关于函数和进程的平均和总内存使用情况.
对于初学者来说,分析单个模块就足够了,它不会产生进程,只会调用它的函数.这已经有所帮助,因为我可以将程序分离到不同的模块进行测试.
典型的可疑点是,正在处理更大的列表.
这里的用法++已经通过lists:reverse([Head|Tail])类似的语法解决了.
我也在考虑使用ETS表而不是列表来处理超过几百个元素的情况.
先感谢您!
我想知道如何分析我的代码.
我已经阅读了文档,但由于没有给出任何例子,我无法从中得到任何结果.
我有一个很大的代码,它花了很多时间,因此我想分析并提高其速度.我没有在方法中编写我的代码,其间很少但不完全.我的代码中没有任何主要内容.我想知道如何使用分析.我正在寻找关于如何分析的一些示例或示例代码.
我尝试了psyco,即在我的代码顶部添加两行:
import psyco
psyco.full()
这是正确的吗？它没有表现出任何改善.任何其他加速方式,请建议.
我希望描述CPU(尽可能的样本),尽可能小的性能影响(因此类似于GCC -pg),使用Clang编译的二进制文件.是否有替代方法使用代码检测,或产生类似于gprof的输出？
我想创建一个装饰器,用于描述方法并记录结果.如何才能做到这一点？
在我们的应用程序的Linux版本中,我需要一个用于嵌入式探查器的高分辨率计时器.我们的分析器测量的范围与单个功能一样小,因此它需要一个优于25纳秒的定时器精度.
以前我们的实现使用内联汇编和rdtsc操作直接从CPU查询高频定时器,但这是有问题的,需要经常重新校准.
所以我尝试使用该clock_gettime函数来查询CLOCK_PROCESS_CPUTIME_ID.文档声称这给了我纳秒时间,但我发现单次调用的开销clock_gettime()超过250ns.这使得不可能将事件计时100ns,并且在计时器功能上具有如此高的开销会严重降低应用程序性能,从而扭曲配置文件超出值.(我们每秒有数十万个分析节点.)
有没有办法调用clock_gettime()开销小于¼μs？或者是否有其他方法可以可靠地获得时间戳计数器,开销<25ns？还是我坚持使用rdtsc？
下面是我过去常用的代码clock_gettime().
// calls gettimeofday() to return wall-clock time in seconds:
extern double Get_FloatTime();
enum { TESTRUNS = 1024*1024*4 };
// time the high-frequency timer against the wall clock
{
double fa = Get_FloatTime();
timespec spec;
clock_getres( CLOCK_PROCESS_CPUTIME_ID, &spec );
printf("CLOCK_PROCESS_CPUTIME_ID resolution: %ld sec %ld nano\n",
spec.tv_sec, spec.tv_nsec );
for ( int i = 0 ; i < TESTRUNS ; ++ i …Valgrind是否有任何已知的误报？我得到一个'条件跳转或移动取决于fmemopen函数的未初始化值' ,用C语言编写并用GCC编译.我能确定这是真的吗？
编辑:抑制文件中是否存在已知问题？在程序中是否可以做一些事情,这不是真正的错误,但Valgrind会说它们是？如果存在已知问题,列表会很好.
所以我有这个基于Makefile的构建系统,我的用户觉得它运行得太慢了.为了这个问题,我们将性能定义为确定实际应该做什么所花费的时间.
我可以看到一些优化途径 -
make -C- 但我想先知道我的瓶颈在哪里.由于没有分析的优化是浪费生命,我想问:如何分析Makefile？
假设我继承的系统设计得相当好,即它已经实现了最常见的交易技巧:(主要是)非递归make,ccache,预编译头,自动生成的头依赖等).
......而且只是为了抢占一些可能的答案.我知道可能会有更快更好的构建系统然后GNU制作 - (就个人而言,我迫不及待地想看看CMake的人会对Ninja系统提出什么) - 但遗憾的是,交换构建系统并不在卡片中.