当前位置: 首页 > 面试题库 >

Commons Lang StringUtils.replace性能vs String.replace

祁修诚
2023-03-14
问题内容

当我比较Apache
StringUtils.replace()与vs的性能时,String.replace()我惊讶地发现前者的速度大约是后者的4倍。我使用Google的Caliper框架来衡量性能。这是我的测试

public class Performance extends SimpleBenchmark {
    String s = "111222111222";

    public int timeM1(int n) {
        int res = 0;
        for (int x = 0; x < n; x++) {
            res += s.replace("111", "333").length();
        }
        return res;
    }

    public int timeM2(int n) {
        int res = 0;
        for (int x = 0; x < n; x++) {
            res += StringUtils.replace(s, "111", "333", -1).length();
        }
        return res;
    }

    public static void main(String... args) {
        Runner.main(Performance.class, args);
    }
}

输出

 0% Scenario{vm=java, trial=0, benchmark=M1} 9820,93 ns; ?=1053,91 ns @ 10 trials
50% Scenario{vm=java, trial=0, benchmark=M2} 2594,67 ns; ?=58,12 ns @ 10 trials

benchmark   us linear runtime
       M1 9,82 ==============================
       M2 2,59 =======

这是为什么?两种方法似乎做同样的工作,StringUtils.replace()甚至更加灵活。


问题答案:

从1的源代码中:java.lang.String

public String replace(CharSequence target, CharSequence replacement) {
   return Pattern
            .compile(target.toString(), Pattern.LITERAL)
            .matcher(this )
            .replaceAll(
                    Matcher.quoteReplacement(replacement.toString()));
}

String.replace(CharSequence target, CharSequence replacement)与实施java.util.regex.Pattern,因此,它是不奇怪的是较慢的是2,这是与实现和。StringUtils.replace(String text, String searchString, String replacement)indexOf``StringBuffer

public static String replace(String text, String searchString, String replacement) {
    return replace(text, searchString, replacement, -1);
}

public static String replace(String text, String searchString, String replacement, int max) {
    if (isEmpty(text) || isEmpty(searchString) || replacement == null || max == 0) {
        return text;
    }
    int start = 0;
    int end = text.indexOf(searchString, start);
    if (end == -1) {
        return text;
    }
    int replLength = searchString.length();
    int increase = replacement.length() - replLength;
    increase = (increase < 0 ? 0 : increase);
    increase *= (max < 0 ? 16 : (max > 64 ? 64 : max));
    StringBuffer buf = new StringBuffer(text.length() + increase);
    while (end != -1) {
        buf.append(text.substring(start, end)).append(replacement);
        start = end + replLength;
        if (--max == 0) {
            break;
        }
        end = text.indexOf(searchString, start);
    }
    buf.append(text.substring(start));
    return buf.toString();
}

脚注

1我链接到并复制源代码的版本是JDK 7

2我链接到并从中复制源代码的版本是common-lang-2.5



 类似资料:
  • 目录 考虑到性能和架构, Redux “可扩展性” 如何? 每个 action 都调用 “所有的 reducer” 会不会很慢? 在 reducer 中必须对 state 进行深拷贝吗?拷贝 state 不会很慢吗? 怎样减少 store 更新事件的数量? 仅有 “一个 state 树” 会引发内存问题吗?分发多个 action 会占用内存空间吗? 缓存远端数据会造成内存问题吗? 性能 考虑到性能

  • Sketch 的性能可以轻松的支持相当复杂的设计,但如果你创作出了一个很大的文件,你可能会想知道有哪些因素影响着 sketch 的性能。 模糊 模糊是非常消耗系统资源的效果。Sketch 需要先将图层渲染成一个位图(这已经很消耗资源了),然后再在上面添加一个模糊(这将更消耗资源),模糊半径越大,消耗的资源也就越大。 一个半径为 1px的模糊,Sketch 需要检查每一个像素周围的每一个像素,也就是

  • 用户希望他们使用的图形界面具有交互性和流畅性,而这正是你需要越来越多地集中时间和精力的地方。 界面不仅要加载快,还要运行良好, 滚动应该很快,动画和交互应该如丝般流畅。 要编写高性能应用程序,你需要了解 LCUI 如何渲染界面,并确保你编写的代码以及第三方代码尽可能高效地运行。 像素管道 “渲染”就是将组件数据转变为像素数据,这个转变如同一条包含很多区域的单向管道,组件数据经过管道中的每个区域的处

  • 性能工具 Reporting: WEIGHTOF.IT Web Page Test GTmetrix Speed Curve [$] Chrome Devtools Timeline sitespeed.io JS tools: ImageOptim-CLI imagemin Budgeting: performancebudget.io

  • jd.onMemoryWarning(function callback) 监听内存不足告警事件,当 iOS/Android 向小程序进程发出内存警告时,触发该事件。 参数 function callback 内存不足告警事件的回调函数 参数 属性 类型 说明 level number 内存告警等级,只有 Android 才有,对应系统宏定义 level 的合法值 值 说明 5 TRIM_MEMO

  • TPS(Transactions Per Second)又称“系统的吞吐量”,即“系统每秒钟能够处理的交易数量”。 当前区块链最大的问题是性能问题。下图为部分公链的单日最大交易量(2019/10/1前的数据)数据来自https://tokenview.com/: 名字 数据日期 交易量 TPS 备注 BitCoin 2017/12/14 490644 5.67875 理论极限为7 Ethereum

  • 如何分析一个由SQLAlchemy支持的应用程序? 查询分析 代码性能测试 执行缓慢 结果获取慢 - 核心 结果获取慢度-ORM 我用ORM插入了400000行,速度非常慢! 如何分析一个由SQLAlchemy支持的应用程序? 寻找性能问题通常涉及两种策略。一个是查询分析,另一个是代码分析。 查询分析 有时只是简单的SQL日志记录(通过python的日志记录模块或通过 echo=True 争论 c