0

我正在尝试分析一个包含创造性命名模块的大型应用程序DB。在没有任何额外的开关或相关的环境变量的情况下运行-d:NYTProf并调用之后，我得到了带有 HTML 输出的常用目录。但是，由于某些内部逻辑，与我的模块相关的任何输出似乎都受到严重破坏。只是为了确定，是纯 Perl。nytprofhtmlnytprofDBDB

  1. 顶部和所有子程序列表：当其他函数链接指向相关-pm-NN-line.html文件时，链接到从DB点到入口脚本的子程序。
  2. “源代码文件”部分中的“行”链接确实指向DB-pm-NN-line.html并且确实存在，但与所有其他文件不同，它内部没有“语句”表，“行”表绝对没有代码行，只有调用摘要.

实际上，这里有一个小例子：

# main.pl
use lib '.';
use DB;

for (1..10) {
    print DB::do_stuff();
}

# DB.pm
package DB;

sub do_stuff {
    my $a = 1;
    my $b = 2;
    my $c = $a + $b;

   return $c;
}

1;

尝试运行perl -d:NYTProf main.pl，然后nytprofhtml再检查nytprof/DB-pm-8-line.html。

我不知道是否会发生这种情况，因为 NYTProf 本身具有命名的内部模块DB，或者它以某种神奇的方式处理以 DB 开头的模块 - 我注意到函数的输出DBI看起来也有些不同。

DB除了重命名我的模块，有没有办法改变/禁用这种行为？

4

1 回答 1

3

这几乎不是一个选择

你真的别无选择。特殊DB包和相关的Devel::命名空间被编码到 perl 编译器/解释器中。除非您想完全不使用任何调试工具并且害怕任何神秘的无法量化的副作用，否则您必须重构代码以重命名您的专有DB库

无论如何，这个名字是非常通用的，这正是它预期会遇到的原因

相反，Devel::NYTProf势必会使用现有的核心包DB。正是因为它是一个非常通用的标识符，工程师应该拒绝将其作为生产代码的选择，这可能需要在任何时候使用预先存在的第三方代码

创造性地命名的模块 DB

这掩盖了您自己对选择的支持。DB自 2000 年 v5.6 以来一直是核心模块，CPAN 中已有的任何内容从一开始就应该被排除在外。我确信命名空间的冲突必须在现在之前被发现。请不要成为把问题扫在地毯下的其他人

请记住，就目前而言，您现在放入DB包中的任何代码都与 perl 已经放入的所有内容共享空间。令人惊讶的是，您还没有出现奇怪和莫名其妙的症状

只要你有一个适合你的 10MB Perl 代码的测试套件，我不认为修复这个问题太大了。如果你不这样做，那么希望你至少不会再犯同样的错误

于 2018-02-05T22:04:14.477 回答