Уважаемые гуру и не очень, есть следующая проблема:
Имеется прибор, с которого приходят данные (оч. часто и много), есть класс приемник, который получает сообщения, форматирует, отображает в логе и пишет в файл. Есть следующий метод который обрезает фрагмернтированные сообщения и клеит в одно


Проблема вот в чём, после получасовой работы, начинаються жуткие тормоза...есть подозрения что "тормозит" именно этот метод.
Может у кого-нить есть предположения как можно его оптимизировать??? читал про StringBuilder, но его средствами я не смог решить задачу. Помогиту плиз   
З.Ы. тормоза заключаюстья в том, что пока идет отображение приходящей строки в лог, система ни на что не откликается.
З.Ы.Ы. Приложение многопоточное.
У кого будут какие-нить соображения???

"После получасовой работы" - однозначно где-то не освобождаются ресурсы операционной системы, например, дескрипторы файлов. То есть, при работе с фалами нужно вызывать Stream.Close(), если же в программе происходит загрузка картинок Image.Dispose() и т.д.

Это сообщение отредактировал(а) anonym - 25.8.2007, 16:29

stashe, да тормоза могут быть именно здесь. Но значительно понятнее это будет если ты запустишь свой код в профайлере и посмотришь, что действительно тормозит.

Я запускал регулярно уборщик мусора,  думал что во время записи в файл, но оказываеться нет...идет эксперимент, приходят данные, пока они "прорисовываються в логе" (строки, за секунду штук 10-15 в среднем), система молчит, как только лог освободился или эксперимент закончен, всё становиться ок. А "После получасовой работы" я забыл добавить что начинают ОСОБЕННО усилино валить данные с прибора, т.е. не обязательно мусор в памяти или что-то с файлами. Я думаю что именно быстродействие операций со строками!
Но как этот код можно оптимизировать??? (писал давно, уже толком и не помню) но смысл таков, что начало команды в строке обозначаеться вторым чаром, а конец третьим, и команды могут прийти порезанные. думаю что StringBuilder не уместен (мож я плохо ковырял).
  

  Я не думаю, что запуск сборщика мусора ручками очень хорошая идея.
  Class String стоит обособлено в .Net в связи с проблемами с производительностью и асинхронным доступом. За это приходится расплачиваться тем, что строка не изменяемая, то есть когда проводишь операцию над строкой, то всегда создается новая строка, которая потом удаляется при сборке мусора. В итоге, если твой метод (а он я так подозреваю вызывается асинхронно) вызвать тучу раз, то вызов сборщика мусора участится, отсюда могут быть тормоза.  
  Альтернативы: StringBuilder имеет ссылку на массив Char'ов, и поскольку переменные temp и temp_buf объявлены вне метода, то можно использовать StringBuilder, новые строки не будут создаваться. 
  Вторая альтернатива: тут уже вопрос в специфике задачи. Дело в том, что строки, которые создаются не "совсем" динамически в коде выносятся как будто это константы (с одной точки зрения так и есть). То есть если напишешь string alpha = "Nepokornie zusuli"; string beta = "Nepokornie zusuli" , то на самом деле alpha и beta ссылаются на одну и ту же переменную. На этом можно получить выгоду, если использовать как можно больше нединамически создаваемых объектов, то CLR будет "играть" с ссылками на эти объекты, что очень шустро. Но, соответственно, это только в том случае, когда можно позволить, что довольно редко.
  Про StringBuilder и String хорошо написано в Рихтере.

та знаю я,но к сожалению это мне никак не помогеает оптимизировать
  

Чтоб я так жил объяснениями. 
1. У тебя в коде есть операции соединения строк и удаления символа из строки. Его можно реализовать с помощью StringBuilder, соответственно используя методы Append и Remove. Для примеров этого - сюда (правда там с примерами по языковой принадлежности они напутали), да и гугл никто не отменял. 
2. Насчет второй альтернативы - это надо узнавать, какого вида бывает переменная message. Если разнообразие сильно ограничено, то это возможно. 

Едрён батон!!!  Читал раньше про стрингбилдер, но показалось что нет методов удаления символов...щяз глянул повнимательнее, ЕСТЬ ОКАЗЫВАЕТЬСЯ   
Zapozidon, HalkaR, anonym  спасибо за то что уделили время моей проблеме!!!