我想知道Java的字符串编码转换算法是多么昂贵,例如,EBCDIC中的一段文本需要转换为UTF-16,或者对大文件进行类似的转换。这次转换的成本是否有任何基准?多种编码的基准会更好。
答案 0 :(得分:3)
这是一种O(n)算法。执行所花费的时间将或多或少地随着您正在转换的字符串的长度线性增加(尽管如果您要转换数百万个非常短的字符串,函数调用的开销将增加此值。)
在几乎所有情况下,这都不会成为瓶颈。您可以在可忽略的时间内编码大小为数十兆字节的字符串。我虽然没有实际的基准数据。
答案 1 :(得分:1)
我怀疑它可以忽略不计。如果您要转换数千个字符串,或者如果要转换非常大的字符串,则会更加分配新的字符串数组,我会更担心分配新String对象的成本。但即便如此,只有在极端情况下。
答案 2 :(得分:0)
这是一个相当微不足道的开销 - Java的字符串算法通常非常好,并且多年来已经过很好的优化。
这并不是说创建一个更高效的专用算法或者可能是优化的本机代码库的接口是不可能实现几个百分点的额外性能。但除非你有很多服务器,其中编码占用了大部分CPU时间,否则不值得付出努力。