Re: StringBuffer vs. StringBuilder

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: StringBuffer vs. StringBuilder
Дата
Msg-id CADK3HHL+ECTxnV0A5VfV-QPP8w3=YY_47Kf5NdB=2CEOUL146w@mail.gmail.com
обсуждение исходный текст
Ответ на StringBuffer vs. StringBuilder  (Frederik Wiers <frederik.wiers@gmail.com>)
Список pgsql-jdbc
Frederik,

Statement caching has been a fairly hot topic of late. What would you expect statement caching to give you ?

Currently we don't really parse the statements. So parsing isn't a huge overhead, but there is some.
We don't use a named statement on the server so that is relatively quick.

I'd be interested in seeing a proof of concept with some performance numbers if you have some cycles?

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca


On Sun, Jan 19, 2014 at 7:37 PM, Frederik Wiers <frederik.wiers@gmail.com> wrote:
Hello,

suggestion for a small performance improvement: replace StringBuffer with StringBuilder when the StringBuffer is used as a local variable in a method.

I just browsed the git-repo (https://github.com/pgjdbc/pgjdbc/tree/master/org/postgresql) looking for prepared statement caching (which I could not find, but that is for another day) and saw a lot of places where StringBuffer can be replaced by StringBuilder.

The little performance test shown at http://stackoverflow.com/a/2771852/3080094
indicates that if StringBuffer is used a lot, replacing it with StringBuilder can make a difference. And I can not think of a reason to use a StringBuffer if it is just used locally in a method to build a String.

Frederik



В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Jeremy Whiting
Дата:
Сообщение: Re: Performance improvement proposal. Removal of toLowerCase calls. PR
Следующее
От: Florian Weimer
Дата:
Сообщение: Re: revisiting unix domain sockets