Иммутабельность строк?

Question

[Griboks]

1) В чём преимущество неизменяемости строк? В c# операции со строками возвращают новые объект. Далее в справке написано, что это очень сильно влияет на производительность. Тогда зачем эта хеш-таблица строк вообще существует? Какие плюсы, какие минусы?

2) Пишу программу, которая постоянно работает со строками (много раз в секунду). Причём строки используются не только для отображения текста, но и для кодирования чисел, логических значений и т.п. Планирую положится на "мозги" языка в этом вопросе. Но какой способ хранения, обработки и конвертирования строк наиболее оптимальный в данном случае?

3) Пишу на C# и JavaScript. Какие методы, встроенные в эти языки, лучше всего будет использовать? В шарпе сейчас использую StringBuilder.

Answer 1

[Sumor]

1. Неизменяемость строк используется при операциях сравнения - сравниваются только указатели. Ещё есть вопросы экономии места при повторном использовании, но не уверен, что здесь можно много выиграть.
2. Для активной работы со строками как раз и используются StringBuilder. по сути они представляют собой выделенный массив большого размера, в рамках которого происходит работа со строкой. Во время манипуляций новый массив не создаётся - всё происходит по месту, если не превышается выделенный размер. Если буфера не хватит - выделяется новый, большего размера. Текущий размер буфера можно узнать из свойства Capacity, его можно сразу задать достаточно большим.

Comments

[Griboks]

Алексей Ситников, я так понимаю, что в оперативную память загружается только одна строка.

[Sumor]

Язык так устроен, что если у вас получается строка, которая уже используется в программе, то вам присвоят тот же указатель. То есть при чтении из базы данных, если строка совпадает со строкой пользователя, то она сразу будет указывать на одно и то же место.

[Sumor]

Я немного ошибся. То, что я описал, называется Intern и может использоваться программистами через использование функции String.Intern. В этом случае строки располагаются по одному разу в памяти. Попарного сравнения не происходит - считаются и сравниваются хеши строк.

Answer 2

[D3lphi]

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

Для того, чтобы произвести, какие-либо операции над строкой, нужно изменить массив символов.

Comments

[Griboks]

Следовательно, нужно совершить эту самую ресурсоёмкую операцию и скопировать весь массив. Зачем же тогда это неудобство встроено в шарп?

Почему бы не использовать указатели разрыва? Ведь если шанс, что следующий участок свободен, глупо копировать весь массив, когда можно его дополнить. А если нет, то скопировать его конец+новые символы в новый участок памяти, заменим старые значения на указатель продолжения массива.

[Станислав Силин]

Griboks, Это порождает много проблем с оценкой производительности. Так например сейчас есть свободной участок все случилось быстро, через секунду все медленно и как вы прикажете програмисту понять в чем проблема? Это очень страный баг или просто фича рантайма? Намного лучше когда ты можеш включить профайлер и посмотреть что там реально происходит, а с такой реализацией это просто не возможно.

Answer 3

[Артем Кустиков]

1) Любые операции сравнения и сортировки строк работают намного быстрее. Часто используемые Dictionary словари получаются очень быстрыми. И самое главное - строки в дотнете thread-safe
2)/3) Не надо преждевременной оптимизации, стандартных методов более чем достаточно, для конкатенации строк - темплейтные строки ($""), StringBuilder или стримы, если объемы очень большие. Строки же для "кодирования чисел" - это что-то нездоровое в архитектуре.

Comments

[Griboks]

Любой тип данных - это строка, иначе откуда взялось значение, если не было напечатано на клавиатуре?

[Артем Кустиков]

Вот только "философии" не надо. Я указал на конкретный косяк - если в программе используются числовые данные, то в памяти они должны храниться именно числами. Для случая "напечатано на клавиатуре" - parseInt/isNaN/isFinite и дальше работа с числами.

[Griboks]

Артем Кустиков, так ведь любая буква тоже в памяти хранится как число.

[Артем Кустиков]

:-) Удачи в поедании кактусов. Решил помочь по доброте душевной, но не к коня корм.

Answer 4

[profesor08]

Если ты можешь взять, выделить любой кусок памяти под свои нужды, а потом взять и расширить его, без выделения нового участка с нужным размером, то таким способом ты сможешь решить свою проблему. Просто сделай это, в C# есть все необходимое для работы с памятью. Но сможешь ли ты с этим справиться, чтоб не возникало ошибок и будет ли это решение быстрее банального копирования одного участка памяти в другой?