Длина строковых переменных и столбцов с символами

Question

Я стремлюсь сделать длину строки символов некоторой степенью двойки (16, 32, 64). Есть ли какая-либо польза от оптимизации в этом для объектов типа string, таких как строковая переменная, набор строк или столбец в базе данных типа string? Это в среде сервера .net / sql.

Answer 1

Поскольку строки .NET не заканчиваются нулем, вам нужно быть очень умным, чтобы фактически использовать идеальное количество символов в каждой отдельной строке.

String message = "hello world!!!!!"; // Exactly 16 chars

Кроме того, размер строк в степени двойки важен только тогда, когда ваша реализация использует «malloc» для распределения памяти. Это стратегия распределения памяти, которая гласит: «Мои отдельные кусочки памяти будут лучше вписываться в кучу, с меньшим количеством потерянного пространства, если все они будут иметь степень двойки».

Но .NET не использует malloc для выделения памяти. Вместо этого вся память кучи выделяется путем увеличения указателя кучи. Когда GC освобождает память позже, он выполняет сжатие кучи, так что вся новая память приходит с конца, и ему никогда не нужно находить маленький фрагмент памяти в фрагментированной куче.

Answer 2

Для столбца в базе данных: знать о страницах данных SQL размером 8 КБ. Чем меньше строк, тем больше строк вы можете разместить на каждой странице данных. Чем больше строк вы можете разместить в каждой странице данных, тем быстрее будут считываться эти строки (чем меньше страниц, тем меньше IO). Это относится как к таблицам, так и к индексам.

Вот еще немного информации из Википедии .

Answer 3

Строки в C # /. Net являются неизменяемыми, поэтому нет смысла (или какого-либо способа) предварительно выделять пространство для хранения большего количества символов при построении строки. Если вы добавляете строку, вы получаете новую строку обратно, она создает новое пространство для хранения всей новой строки и не перераспределяет. Что касается столбцов SQL, вы должны сделать их точной длиной строки, если вы знаете ее заранее (char (N)) или использовать переменные символьные данные (varchar (N)), с N выбранным в качестве подходящего максимума. Я не вижу смысла в том, чтобы держать их в силе двух - SSMS по умолчанию равняется 50, когда вы создаете столбец varchar, так что, очевидно, и Microsoft не делает.

Единственное место, в котором предварительное распределение может иметь значение, - это что-то вроде StringBuilder или предварительное распределение размера коллекции. Опять же, он должен быть рассчитан таким образом, чтобы его не нужно было изменять, но он должен быть близок к его фактическому использованию, если оно известно. Если неизвестно, либо пропустите начальный размер или сделайте его достаточно большим, чтобы вместить большинство случаев.

Answer 4

Нет. Что бы вы делали с фрагментом строки, который вы не используете, потому что это просто заполнение. Стоимость таких потерь будет значительной по сравнению с любой возможной экономией при попытке выровнять строки. Очень сомнительно, что такая длина принесет какую-либо пользу.

Answer 5

Нет. Оптимизация размеров в два раза произошла с самого начала эры баз данных и имела отношение к тому, как данные были выровнены на диске и в памяти. Сегодня это рудиментарное поведение, которое не дает никаких преимуществ.

Answer 6

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