java JIT——可以进行哪些优化?
学术上好奇。 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
理论上,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.