Java性能优化[2]:字符串过滤实战

  上一个帖子 已经介绍了基本类型和引用类型的性能差异(主要是由于内存分配方式不同导致)。为了给列位看官加深印象,今天拿一个具体的例子来实地操作一把,看看优化的效果如何。<!-- program-think-->

  ★关于需求
  首先描述一下需求,具体如下:给定一个String对象,过滤掉除数字 (字符'0'-'9')以外的其它字符。要求时间开销尽可能小。过滤函数的原型如下:String filter(String str);
   针对上述需求,我写了5个不同的过滤函数。为了叙述方便,分别称为filter1到filter5。其中filter1性能最差、filter5性能最 好。在你接着看后续的内容之前,你先暗自思考一下,如果由你来实现该函数,大概会写成什么样?最好把你想好的函数写下来,便于后面的对比。

  ★代码实现

  ◇测试代码
  为了方便测试性能,先准备好一个测试代码,具体如下:


class Test
{
public static void main(String[] args)
{
if(args.length != 1)
{
return;
}

String str = "";
long nBegin = System.currentTimeMillis();
for(int i=0; i<1024*1024; i++)
{
str = filterN(args[0]); //此处调用某个具体的过滤函数
}
long nEnd = System.currentTimeMillis();

System.out.println(nEnd-nBegin);
System.out.println(str);
}
};


   在没有想好你的实现方式之前,先别偷看后续内容哦!另外,先注明一下,我使用的Java环境是JDK 1.5.0-09,使用的测试字符串为“D186783E36B721651E8AF96AB1C4000B”。由于JDK版本和机器性能不尽相同,你在 自己机器上测试的结果可能和我下面给出的数值不太一样。


  ◇版本1
  先来揭晓性能最差的filter1,代码如下:


private static String filter1(String strOld)
{
String strNew = new String();
for(int i=0; i<strOld.length(); i++)
{
if('0'<=strOld.charAt(i) && strOld.charAt(i)<='9')
{
strNew += strOld.charAt(i);
}
}
return strNew;
}


  如果你的代码不幸和filter1雷同,那你的Java功底可就是相当糟糕了,连字符串拼接需要用StringBuffer来优化都没搞明白。
  为了和后续对比,先记下filter1的处理时间,大约在8.81-8.90秒之间。

  ◇版本2
  再来看看filter2,代码如下:


private static String filter2(String strOld)
{
StringBuffer strNew = new StringBuffer();
for(int i=0; i<strOld.length(); i++)
{
if('0'<=strOld.charAt(i) && strOld.charAt(i)<='9')
{
strNew.append(strOld.charAt(i));
}
}
return strNew.toString();
}


   其实刚才在评价filter1的时候,已经泄露了filter2的天机。filter2通过使用StringBuffer来优化连接字符串的性能。为什 么StringBuffer连接字符串的性能比String好,这个已经是老生常谈,我就不细说了。尚不清楚的同学自己上Google一查便知。我估计应 该有挺多同学会写出类似filter2的代码。
  另外,JDK 1.5新增加了StringBuilder,性能会比StringBuffer更好,不过考虑到有可能要拿到其它版本的JDK上作对比测试,而且 StringBuilder和StringBuffer之间的差异不是本文讨论的重点,所以后面的例子都使用StringBuffer来实现。
  filter2的处理时间大约为2.14-2.18秒,提升了大约4倍。

  ◇版本3
  接着看看filter3,代码如下:


private static String filter3(String strOld)
{
StringBuffer strNew = new StringBuffer();
int nLen = strOld.length();
for(int i=0; i<nLen; i++)
{
char ch = strOld.charAt(i);
if('0'<=ch && ch<='9')
{
strNew.append(ch);
}
}
return strNew.toString();
}


   乍一看filter3和filter2的代码差不多嘛!你再仔细瞧一瞧,原来先把strOld.charAt(i)赋值给char变量,节省了重复调用 charAt()方法的开销;另外把strOld.length()先保存为nLen,也节省了重复调用length()的开销。能想到这一步的同学,估 计是比较细心的。
  经过此一优化,处理时间节省为1.48-1.52,提升了约30%。由于charAt()和length()的内部实现都挺简单的,所以提升的性能不太明显。
  另外补充一下,经网友反馈,在JDK 1.6上,filter3和filter2的性能基本相同。可能是由于JDK 1.6已经进行了相关的优化。

  ◇版本4
  然后看看filter4,代码如下:


private static String filter4(String strOld)
{
int nLen = strOld.length();
StringBuffer strNew = new StringBuffer(nLen);
for(int i=0; i<nLen; i++)
{
char ch = strOld.charAt(i);
if('0'<=ch && ch<='9')
{
strNew.append(ch);
}
}
return strNew.toString();
}


  filter4和filter3差别也很小,唯一差别就在于调用了StringBuffer带参数的构造函数。通过StringBuffer的构造函数设置初始的容量大小,可以有效避免append()追加字符时重新分配内存,从而提高性能。
  filter4的处理时间大约在1.33-1.39秒。约提高10%,可惜提升的幅度有点小 :-(

  ◇版本5
  最后来看看终极版本,性能最好的filter5。


private static String filter5(String strOld)
{
int nLen = strOld.length();
char[] chArray = new char[nLen];
int nPos = 0;
for(int i=0; i<nLen; i++)
{
char ch = strOld.charAt(i);
if('0'<=ch && ch<='9')
{
chArray[nPos] = ch;
nPos++;
}
}
return new String(chArray, 0, nPos);
}


  猛一看,你可能会想:filter5和前几个版本的差别也忒大了吧!filter5既没有用String也没有用StringBuffer,而是拿字符数组进行中间处理。
  filter5的处理时间,只用了0.72-0.78秒,相对于filter4提升了将近50%。为啥捏?是不是因为直接操作字符数组,节省了append(char)的调用?通过查看append(char)的源代码,内部的实现很简单,应该不至于提升这么多。
  那是什么原因捏?
   首先,虽然filter5有一个字符数组的创建开销,但是相对于filter4来说,StringBuffer的构造函数内部也会有字符数组的创建开 销。两相抵消。所以filter5比filter4还多节省了StringBuffer对象本身的创建开销。(在我的JDK 1.5环境中,这个因素比较明显)
  其次,由于StringBuffer是线程安全的(它的方法都是synchronized),因此调用它的方法有一定的同步开销,而字符数组则没有,这又是一个性能提升的地方。(经网友反馈,此因素在JDK 1.6中比较明显)
  基于上述两个因素,所以filter5比filter4又有较大幅度的提升。

  ★对于5个版本的总结
   上述5个版本,filter1和filter5的性能相差约12倍(已经超过一个数量级)。除了filter3相对于filter2是通过消除函数重复 调用来提升性能,其它的几个版本都是通过节省内存分配,降低了时间开销。可见内存分配对于性能的影响有多大啊!如果你是看了上一个帖子 才写出filter4或者filter5,那说明你已经领会了个中奥妙,我那个帖子也就没白写了。

  ★一点补充说明,关于时间和空间的平衡
  另外,需要补充说明一下。版本4和版本5使用了空间换时间的手法来提升性能。假如被过滤的字符串很大 ,并且数字字符的比例很低 ,这种方式就不太合算了。
   举个例子:被处理的字符串中,绝大部分都只含有不到10%的数字字符,只有少数字符串包含较多的数字字符。这时候该怎么办捏?对于filter4来说, 可以把new StringBuffer(nLen);修改为new StringBuffer(nLen/10);来节约空间开销。但是filter5就没法这么玩了。
  所以,具体该用版本4还是版本5,要看具体情况了。只有在你非常 看重时间开销,且数字字符比例很高(至少大于50%)的情况下,用filter5才合算。否则的话,建议用filter4。

  下一个帖子,打算介绍一下“关于垃圾回收(GC) ”的话题。


版权声明
本博客所有的原创文章,作者皆保留版权。转载必须包含本声明,保持本文完整,并以超链接形式注明作者编程随想 和本文原始地址:

http://program-think.blogspot.com/2009/03/java-performance-tuning-2-string.html

内容概要:本文介绍了一个基于多传感器融合的定位系统设计方案,采用GPS、里程计和电子罗盘作为定位传感器,利用扩展卡尔曼滤波(EKF)算法对多源传感器数据进行融合处理,最终输出目标的滤波后位置信息,并提供了完整的Matlab代码实现。该方法有效提升了定位精度与稳定性,尤其适用于存在单一传感器误差或信号丢失的复杂环境,如自动驾驶、移动采用GPS、里程计和电子罗盘作为定位传感器,EKF作为多传感器的融合算法,最终输出目标的滤波位置(Matlab代码实现)机器人导航等领域。文中详细阐述了各传感器的数据建模方式、状态转移与观测方程构建,以及EKF算法的具体实现步骤,具有较强的工程实践价值。; 适合人群:具备一定Matlab编程基础,熟悉传感器原理和滤波算法的高校研究生、科研人员及从事自动驾驶、机器人导航等相关领域的工程技术人员。; 使用场景及目标:①学习和掌握多传感器融合的基本理论与实现方法;②应用于移动机器人、无人车、无人机等系统的高精度定位与导航开发;③作为EKF算法在实际工程中应用的教学案例或项目参考; 阅读建议:建议读者结合Matlab代码逐行理解算法实现过程,重点关注状态预测与观测更新模块的设计逻辑,可尝试引入真实传感器数据或仿真噪声环境以验证算法鲁棒性,并进一步拓展至UKF、PF等更高级滤波算法的研究与对比。
内容概要:文章围绕智能汽车新一代传感器的发展趋势,重点阐述了BEV(鸟瞰图视角)端到端感知融合架构如何成为智能驾驶感知系统的新范式。传统后融合与前融合方案因信息丢失或算力需求过高难以满足高阶智驾需求,而基于Transformer的BEV融合方案通过统一坐标系下的多源传感器特征融合,在保证感知精度的同时兼顾算力可行性,显著提升复杂场景下的鲁棒性与系统可靠性。此外,文章指出BEV模型落地面临大算力依赖与高数据成本的挑战,提出“数据采集-模型训练-算法迭代-数据反哺”的高效数据闭环体系,通过自动化标注与长尾数据反馈实现算法持续进化,降低对人工标注的依赖,提升数据利用效率。典型企业案例进一步验证了该路径的技术可行性与经济价值。; 适合人群:从事汽车电子、智能驾驶感知算法研发的工程师,以及关注自动驾驶技术趋势的产品经理和技术管理者;具备一定自动驾驶基础知识,希望深入了解BEV架构与数据闭环机制的专业人士。; 使用场景及目标:①理解BEV+Transformer为何成为当前感知融合的主流技术路线;②掌握数据闭环在BEV模型迭代中的关键作用及其工程实现逻辑;③为智能驾驶系统架构设计、传感器选型与算法优化提供决策参考; 阅读建议:本文侧重技术趋势分析与系统级思考,建议结合实际项目背景阅读,重点关注BEV融合逻辑与数据闭环构建方法,并可延伸研究相关企业在舱泊一体等场景的应用实践。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值