java JIT——可以进行哪些优化?

发布于 2024-10-16 00:39:15 字数 582 浏览 3 评论 0原文

学术上好奇。 JIT 是否可以采用这样的代码,认识到格式字符串是静态最终的,从而预先计算切片格式字符串,从而将其优化为仅具有最少附加的 StringBuilder ?

public static String buildDeleteSql(BaseObject object)
{
    String table;
    String schema;

    String deleteSql = String.format(
            "DELETE FROM %s.%s WHERE %s = '%s' AND %s = '%s'",
            schema,
            table,
            BaseObject.ATTR_ID,
            StringUtils.escapeForSQLString(object.getId()),
            BaseObject.ATTR_REVISION,
            StringUtils.escapeForSQLString(object.getRevision())
        );

    return deleteSql;
}

Academically curious. Can the JIT take code like this, recognize that the format string is static final and thus precompute the sliced format string, thus optimizing this down to only StringBuilder with minimal appends?

public static String buildDeleteSql(BaseObject object)
{
    String table;
    String schema;

    String deleteSql = String.format(
            "DELETE FROM %s.%s WHERE %s = '%s' AND %s = '%s'",
            schema,
            table,
            BaseObject.ATTR_ID,
            StringUtils.escapeForSQLString(object.getId()),
            BaseObject.ATTR_REVISION,
            StringUtils.escapeForSQLString(object.getRevision())
        );

    return deleteSql;
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

小忆控 2024-10-23 00:39:15

理论上,JVM 可能可以理解您的示例。与此同时,实际上,现有的 JVM 不会;将预算用于优化可能不是一个非常有利可图的地方。特别是因为字符串格式化通常是为了序列化数据,在这种情况下,您可能最终会花费大部分时间等待 I/O 完成。

Theoretically, a JVM could probably grok your example. Meantime, in reality, existing JVMs won't; it's probably not a very lucrative place to spend the budget for optimizations. Especially since string formatting is usually done to serialize data, in which case you'll probably end up spending most of the time waiting for I/O to complete.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文