maven2的一个性能bug

最近用maven2.2.1编译应用,发现竟然要5min。而类似代码规模的另一个应用,编译只要1min。查了一下,原因还是很狗血。

[INFO] ------------------------------------------------------------------------
[INFO] app-1

[INFO] Total time: 5 minutes 48 seconds
[INFO] Finished at: Sat Jan 19 15:52:09 HKT 2013
[INFO] Final Memory: 453M/1536M
[INFO] ------------------------------------------------------------------------

[INFO] ------------------------------------------------------------------------
[INFO]  app-2

[INFO] Total time: 1 minute 52 seconds

[INFO] Finished at: Sat Jan 19 15:48:31 HKT 2013
[INFO] Final Memory: 370M/986M
[INFO] ------------------------------------------------------------------------


1\ 开始走了两个误区

开始发现gc比较夸张,一秒full一次,所以调了ms,结果一样慢。

后来jstack看到很多异常栈。发现是 Integer.valueOf("RELEASE")搞出来的,修改maven打包,还是很慢。

2\ profile

没有办法,默默鄙视自己100次,然后装了jprofiler。
cpu profile一看,问题就基本定位了。


两个应用都调用了 retrieveRelocatedArtifact,但是慢的那个占比明显多。很可能是调用次数变多。

于是再默默鄙视自己100次,手工加count,然后shutdownhook里打印出来(不会用btrace的人伤不起啊。。。)。发现是buildFromRepository开始变多的。

debug了下代码,发现是因为使用RELEASE版本号(LATEST类似)之后,maven编译的一个缓存map失效了(名字对不起来),具体原因是:

maven内部使用了一个map缓存每次parse pom文件的结果。使用RELEASE之后,缓存的key不固定。查找key的格式是“com.foo:bar:RELEASE”,但设置key的格式变成“com.foo.bar:1.0.1”,也就是具体的版本号。所以对RELEASE版本的依赖会重复处理,工程越多(pom越多),重复越多,速度也就越慢。

看看代码也许更明白:

public class DefaultMavenProjectBuilder extends AbstractLogEnabled
implements MavenProjectBuilder, Initializable, Contextualizable
{
private Map processedProjectCache = new HashMap();
 
public MavenProject buildFromRepository( Artifact artifact,...) {
    String cacheKey = createCacheKey( artifact.getGroupId(), artifact.getArtifactId(), artifact.getVersion() );   //  <=========   the "get key"
    MavenProject project = (MavenProject) processedProjectCache.get( cacheKey );
    if ( project != null )
    {
        return project;
    }
    Model model = findModelFromRepository( artifact, remoteArtifactRepositories, localRepository, allowStubModel );
    ProjectBuilderConfiguration config = new DefaultProjectBuilderConfiguration().setLocalRepository( localRepository );
    MavenProject mavenProject = buildInternal("Artifact [" + artifact + "]", model, config, remoteArtifactRepositories,
            null, false);
 
    return mavenProject;
}
 
private MavenProject buildInternal(String pomLocation,
                                   Model model,
                                   ProjectBuilderConfiguration config,
                                   List parentSearchRepositories,
                                   File projectDescriptor,
                                   boolean strict, String cacheKey)
    throws ProjectBuildingException
{
    //...
    cacheKey = createCacheKey( project.getGroupId(), project.getArtifactId(), project.getVersion() );   //  <=========   the "set key"
    processedProjectCache.put( cacheKey, project );
    //...
}
}

3\ 修改对应代码,重新编译

[INFO] ------------------------------------------------------------------------
[INFO] app-1
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 57 seconds
[INFO] Finished at: Sat Jan 19 17:11:40 HKT 2013
[INFO] Final Memory: 422M/1004M
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] app-2
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 58 seconds
[INFO] Finished at: Sat Jan 19 17:10:35 HKT 2013
[INFO] Final Memory: 350M/941M
[INFO] ------------------------------------------------------------------------


4\ 关于REELASE和LATEST的补充说明

maven论坛很多帖说LATEST和RELEASE已经不推荐使用。maven官网的mvnref-book里的对应章节也找不到关于LASTEST和RELEASE的描述了。

https://issues.sonatype.org/browse/MVNREF-23
http://maven.40175.n5.nabble.com/LATEST-RELEASE-dependency-version-td124018.html

http://stackoverflow.com/questions/30571/how-do-i-tell-maven-to-use-the-latest-version-of-a-dependency


所以,把上面的bug提到stackoverflow以后,一个maven的commiter说别用RELEASE了。

于是,我也不好说啥了。

5\ 如何编译maven

5.1\
从 http://maven.apache.org/download.cgi 下载source

5.2\
cd /home/brian/work.sc/maven_src/apache-maven-2.2.1;
export M2_HOME=/home/brian/Desktop/apache-maven-2.2.1; export PATH=$M2_HOME/bin:$PATH
ant;


5.3\
cd $path_to_your_app;
export M2_HOME=/home/brian/Desktop/apache-maven-2.2.1;  export PATH="$M2_HOME/bin:$PATH
mvn clean install -Dmaven.test.skip  -Dcheck.parent.skip=false

ps, edit `which mvn` to enable remote debug


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在信号处理领域,DOA(Direction of Arrival)估计是一项关键技术,主要用于确定多个信号源到达接收阵列的方向。本文将详细探讨三种ESPRIT(Estimation of Signal Parameters via Rotational Invariance Techniques)算法在DOA估计中的实现,以及它们在MATLAB环境中的具体应用。 ESPRIT算法是由Paul Kailath等人于1986年提出的,其核心思想是利用阵列数据的旋转不变性来估计信号源的角度。这种算法相比传统的 MUSIC(Multiple Signal Classification)算法具有较低的计算复杂度,且无需进行特征值分解,因此在实际应用中颇具优势。 1. 普通ESPRIT算法 普通ESPRIT算法分为两个主要步骤:构造等效旋转不变系统和估计角度。通过空间平移(如延时)构建两个子阵列,使得它们之间的关系具有旋转不变性。然后,通过对子阵列数据进行最小二乘拟合,可以得到信号源的角频率估计,进一步转换为DOA估计。 2. 常规ESPRIT算法实现 在描述中提到的`common_esprit_method1.m`和`common_esprit_method2.m`是两种不同的普通ESPRIT算法实现。它们可能在实现细节上略有差异,比如选择子阵列的方式、参数估计的策略等。MATLAB代码通常会包含预处理步骤(如数据归一化)、子阵列构造、旋转不变性矩阵的建立、最小二乘估计等部分。通过运行这两个文件,可以比较它们在估计精度和计算效率上的异同。 3. TLS_ESPRIT算法 TLS(Total Least Squares)ESPRIT是对普通ESPRIT的优化,它考虑了数据噪声的影响,提高了估计的稳健性。在TLS_ESPRIT算法中,不假设数据噪声是高斯白噪声,而是采用总最小二乘准则来拟合数据。这使得算法在噪声环境下表现更优。`TLS_esprit.m`文件应该包含了TLS_ESPRIT算法的完整实现,包括TLS估计的步骤和旋转不变性矩阵的改进处理。 在实际应用中,选择合适的ESPRIT变体取决于系统条件,例如噪声水平、信号质量以及计算资源。通过MATLAB实现,研究者和工程师可以方便地比较不同算法的效果,并根据需要进行调整和优化。同时,这些代码也为教学和学习DOA估计提供了一个直观的平台,有助于深入理解ESPRIT算法的工作原理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值