Хм, но ведь компилятор не всё сможет оптимизировать, например, когда построение итоговой строки зависит от результатов работы функций. Типа:


Или он и такие вещи умеет оптимизировать? Как-то не доверяю я возможностям оптимизации в сложных конструкциях  Лучше уж в таких ситуациях по старинке, со StringBuilder'ом.

А что там сложного оптимизировать?


Она скорее даже ещё улучшится.

В любом случае "грязную рутинную работу" надо оставлять роботам - т.е компилятору. Лучше оптимизатора человек всё равно не соптимирует. 
А вот читабельность должна на первом месте стоять. 

Но конечно setLength(0); - самы быстрый вариант. И такое точно оптимизатор не возьмёт.

Где-то в учебнике видел фразу, что StringBuilder - это несинхронизированная версия StringBuffer' а . Примерно также соотносятся, как Vector и ArrayList. Просто и понятно. А прочитав эту дискуссию, так ничего и не понял. Как же лучше складывать строки в java 6? (в байт код не отсылайте  )

COVD, плюсом.

Только не в циклах.


Я бы с радостью восполнил пробел в образовании, если бы он был 

Упомянутая вами "оптимизация" имела место ещё в версии 1.4.0 (возможно и в более ранних, я не интересовался). И заключается она _только_ в подмене операций со строками на операции со StringBuffer'ом (до 1.5) или StringBuilder'ом. Это я за оптимизацию не считаю вовсе.

Конкатенация строк вида 

преобразуется компилятором в код, создающий два-три (зависит от ситуации) _лишних_ объекта. При этом расходуется _как минимум_ в полтора раза больше памяти, чем при использовании StringBuilder'а. Именно эта "оптимизация", помещённая в цикл, и приводит к огромным потерям времени и значительным потерям памяти _впустую_.

З. Ы. Особенно времени. Дополнение StringBuilder'а (каждый может написать для себя простенький тест, дабы убедиться воочию) быстрее конкатенации строк (якобы оптимизируемой) в _тысячи раз_.

Это сообщение отредактировал(а) w1nd - 16.8.2007, 23:41

Тогда везде бы надо StringBuilder использовать. Надо ли понимать так, что str1+str2 - это наглядно и потому хорошо, но в цикле это большая роскошь. 

  

Согласен (иногда бывает наоборот, но речь не об этом). Современный java-компилятор (6-ой, 5-ый...) действительно умеет делать такие оптимизации, как ты привёл в коде?

Такие не умеет. И, смею предположить, не сумеет никогда. Просто на месте каждого сложения будет создан StringBuilder, вызван append, и результат обратно в переменную с помощью toString().

Это сообщение отредактировал(а) w1nd - 17.8.2007, 11:50

На свежую голову провёл эксперимент.

В то время как

экономит три байта и лишний вызов метода append()

Вот такая мелочная оптимизация.

Особенно забавно, что мы не знаем, как реализованы вызовы конструкторов StringBuilder - какой из них эффективнее   

Да ну? Совершенно не согласен. 

Вместо "лучше" следовало бы написать "эффективнее". Это true.

sergejzr, всё равно не согласен. Человек способен оптимизировать куда лучше и эффективнее, чем любой компилятор, оптимизатор и иже с ними. А вот то, что человек затратит на это куда больше времени - это уже как раз true.
То есть, оптимизация выходит у человека эффективнее, но сам процесс оптимизирования у него неэффективен. 

 А что есть по Вашему эффективность?  Уж время это один из главных влияющих факторов. И кто этот абстрактный "человек"? Если среднего программиста взять, то точно оптимизатор лучше, а если крутого, то его сперва надо взять где-то, да и он наврядли будет оптимизировать ваш код. А зачем нам учитывать теоретическую эффективность, которая не может быть достигнута на практике?
ПС:
Не стоит придираться к словам. И так понятно, что имеется ввиду, а то - уходим от темы.





Да, действительно (проверил дисассемблером). Ява оптимизатор оказывается и правда ещё в младенческом возрасте находится. 

Насчёт не сумеет никогда - я бы сомневался. Конструкция не очень тяжёлая. Её возможно даже препроцессором (заменой выражений "побуквенно") можно взять (если бы он у явы был ) )

Под эффективностью я понимал то, что человек может оптимизировать код так, что он (код) после этой процедуры будет эффективнее. Эффективность кода и эффективность процесса оптимизации кода - разные вещи. Думаю, теперь мы разобрались с тем, кто и что имел в виду.

А по поводу уровня "человека" могу сказать то, что объективно нет такого понятия как "средний программист". Так же, как нет и других категорий. Потому что вообще ничего объективного у нас нет. Но это я уже ударился в совсем иные сферы бытия.
Кто же может оптимизировать лучше, чем некий обобщённый оптимизатор? Знамо дело - умный и усидчивый, имеющий достаточно знаний и стимул для этого.
Если вы, уважаемый, работали с ассемблером, то посмотрев на скомпилированный код любого приложения вы сможете заметить хотя бы пару мест, где можно было бы оптимизировать.
Ну и думаю, без объяснений понятно, что человек сначала даст возможность показать себя оптимизатору, а потом уже при необходимости сам полезет оптимизировать. Так и время экономится, и оптимизация увеличивается, если это необходимо.