Ray Augé 14 年之前 I'm sure glad you're on our team Shuyang!Great stuff! 请登录以投票。 以……回复 取消 Shuyang Zhou Ray Augé 14 年之前 Thanks Ray 请登录以投票。 以……回复 取消
Bing Ran 14 年之前 Nice stuff! Will use it in Japid(http://github.com/branaway/Japid), my template engine for the Play framework for max throughput. 请登录以投票。 以……回复 取消 Shuyang Zhou Bing Ran 14 年之前 Glad to know my stuff can help your productYou may also interested in the unsync IO blog. I guess a template engine must do some stream processing. 请登录以投票。 以……回复 取消
Shuyang Zhou Bing Ran 14 年之前 Glad to know my stuff can help your productYou may also interested in the unsync IO blog. I guess a template engine must do some stream processing. 请登录以投票。 以……回复 取消
(你) 12 年之前 [...] String Concatenation Performance vs. String Builder/Buffer and how Liferay 6 achieved a speedup by not using S.B. [that much] – StringBuilder/Buffer has lot of overhead and thus String.concat or... [...] Read More 请登录以投票。 以……回复 取消
James Lefeu 10 年之前 I'm curious whether the benchmarks would change much if we used strings of size 2 or strings of size 300. 请登录以投票。 以……回复 取消
Pavel Savinov 7 年之前 Nice article Shuyang!String in Java is very "interesting" class indeed. As one more step of Liferay Strings optimizations we could also replace all direct substring invocations, like that: String strutsPath = strutsAction.substring(...)wrapping them into new String constructor to save more memory... 请登录以投票。 以……回复 取消 Pavel Savinov Pavel Savinov 7 年之前 Oops, out-of-date comment 请登录以投票。 以……回复 取消