http://stackoverflow.com/questions/472906/net-string-to-byte-array-c-sharp

static byte[] GetBytes(string str)
{
    byte[] bytes = new byte[str.Length * sizeof(char)];
    System.Buffer.BlockCopy(str.ToCharArray(), 0, bytes, 0, bytes.Length);
    return bytes;
}

static string GetString(byte[] bytes)
{
    char[] chars = new char[bytes.Length / sizeof(char)];
    System.Buffer.BlockCopy(bytes, 0, chars, 0, bytes.Length);
    return new string(chars);
}

В функции GetBytes метод ToCharArray()
1) "Copies the characters in this instance to..."
2) "Copies a specified number of bytes from..."

т.е. копируем дважды, когда можно было бы вообще не копировать.

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

Здравствуйте, newCL, Вы писали:

CL>http://stackoverflow.com/questions/472906/net-string-to-byte-array-c-sharp

CL>т.е. копируем дважды, когда можно было бы вообще не копировать.

CL>И так повсюду: везде и всюду такты и байты расходуются ниначто, т.е. выделяется память там, где её выделять не нужно, и делается то, что делать не нужно.

Ничего, что ровно на одно сообщение ниже есть

Internally, the .NET framework uses UTF16 to represent strings, so if you simply want to get the exact bytes that .NET uses, use System.Text.Encoding.Unicode.GetBytes (...).

А от идиотов никакая память не спасет.

Здравствуйте, Mamut, Вы писали:

M>А от идиотов никакая память не спасет.

От идиотов спасает только ее нехватка.

Здравствуйте, newCL, Вы писали:

CL>т.е. копируем дважды, когда можно было бы вообще не копировать.

Нельзя не копировать. Строки в .NET — immutable. А массивы — mutable. Некопирование в такой ситуации означает потерю safety.

Здравствуйте, Mamut, Вы писали:

M>А от идиотов никакая память не спасет.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нельзя не копировать. Строки в .NET — immutable. А массивы — mutable. Некопирование в такой ситуации означает потерю safety.

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

Здравствуйте, newCL, Вы писали:

CL>Это всё равно глупо, т.к. в большинстве случаев байты получают для скармливания алгоритмам хэширования/криптования или отправляются по сети, или в файл пишутся

Переключаешься в unsafe и вперед, если уверен что получишь существенный выигрышь в перформансе.

CL>а safety обязан обеспечивать сам программист.

Вот unsafe как раз и предназначен для случаев, когда программист берет ответственность за корректность программы на себя.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Mamut, Вы писали:

M>>А от идиотов никакая память не спасет.

PD>От идиотов спасает только ее нехватка.

от идиотов ничего не спасёт
http://www.rsdn.ru/forum/dotnet/4782200.1.aspx

Автор:
Дата: 17.06.12

что плохого в копировании? нужен процессинг? делайте LINQ, цикл по символам, String это массив

а нехватка — проблема кастомера.

M>>А от идиотов никакая память не спасет.

PD>От идиотов спасает только ее нехватка.

Нет, от идиотов ничего не спасает. Будет нехватка памяти, будет все к чертям валиться в OOM.

Здравствуйте, Mamut, Вы писали:

M>>>А от идиотов никакая память не спасет.

PD>>От идиотов спасает только ее нехватка.

M>Нет, от идиотов ничего не спасает. Будет нехватка памяти, будет все к чертям валиться в OOM.

Полностью согласен. Регулярно пользуюсь двумя браузерами: Chrome и Firefox. Оба при нехватке памяти молча закрываются. То есть OOM в них не обрабатывается. Где-то в одном случае из десяти лисичка предлагает послать крэш-репорт (что там делает хром — не в курсе). Хорошо хоть оба браузера не теряют открытые вкладки, после запуска корректно всё восстанавливают.

Здравствуйте, koodeer, Вы писали:

K>Полностью согласен. Регулярно пользуюсь двумя браузерами: Chrome и Firefox. Оба при нехватке памяти молча закрываются.
Линуксоид?

Здравствуйте, sdf, Вы писали:

sdf>Здравствуйте, koodeer, Вы писали:

K>>Полностью согласен. Регулярно пользуюсь двумя браузерами: Chrome и Firefox. Оба при нехватке памяти молча закрываются.
sdf>Линуксоид?

Windows. Зависит от того какой chrome.exe навернулся. Если это основной процесс, то браузер просто закроется, если это рабочие процессы — то просто отвалится ряд вкладок.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, sdf, Вы писали:

sdf>>Здравствуйте, koodeer, Вы писали:

K>>>Полностью согласен. Регулярно пользуюсь двумя браузерами: Chrome и Firefox. Оба при нехватке памяти молча закрываются.
sdf>>Линуксоид?
H>Windows.
Телепат?

Здравствуйте, Mamut, Вы писали:

M>Нет, от идиотов ничего не спасает. Будет нехватка памяти, будет все к чертям валиться в OOM.

И это очень хорошо, потому что этих программ не увидит никто, кроме этих идиотов.

M>>Нет, от идиотов ничего не спасает. Будет нехватка памяти, будет все к чертям валиться в OOM.

PD>И это очень хорошо, потому что этих программ не увидит никто, кроме этих идиотов.

Нет, неверно. Синий экран смерти помнишь? Видать, писали такие вот идиоты. Что-то нехватка памяти не привела к тому, что BSOD'а не было, а продукт никто не видел.

В общем, не надо рассказывать сказки про то, как ограниченные ресурсы моментально делают из программистов безгрешных гениев — тошнит уже

Здравствуйте, koodeer, Вы писали:

M>>>>А от идиотов никакая память не спасет.
PD>>>От идиотов спасает только ее нехватка.
M>>Нет, от идиотов ничего не спасает. Будет нехватка памяти, будет все к чертям валиться в OOM.
K>Полностью согласен. Регулярно пользуюсь двумя браузерами: Chrome и Firefox. Оба при нехватке памяти молча закрываются. То есть OOM в них не обрабатывается. Где-то в одном случае из десяти лисичка предлагает послать крэш-репорт (что там делает хром — не в курсе). Хорошо хоть оба браузера не теряют открытые вкладки, после запуска корректно всё восстанавливают.

Лечить идиотов надо начинать с ядра ОС (и все Unix, и Linux, и Windows тут кривы почти одинаково). Ситуация нехватки критических ресурсов, когда невозможно сделать даже аккуратное завершение приложения, должна лечиться при помощи ядра, и не надеяться на виртуальные ресурсы.

Здравствуйте, Mamut, Вы писали:

M>Нет, неверно. Синий экран смерти помнишь? Видать, писали такие вот идиоты. Что-то нехватка памяти не привела к тому, что BSOD'а не было, а продукт никто не видел.

Я думаю, что все же там было что-то иное. Простой нехваткой памяти в 3 кольце BSOD не сотворишь. Или там была ошибка в ядре. Но от ошибок никто не застрахован.

M>В общем, не надо рассказывать сказки про то, как ограниченные ресурсы моментально делают из программистов безгрешных гениев — тошнит уже

А этого я и не утверждал. Просто тех, кто писать не умеет, нехватка памяти приводит в ступор и они переквалифицируются в управдомы

Здравствуйте, newCL, Вы писали:


CL>т.е. копируем дважды, когда можно было бы вообще не копировать.

CL>И так повсюду: везде и всюду такты и байты расходуются ниначто, т.е. выделяется память там, где её выделять не нужно, и делается то, что делать не нужно.

Это позволяет сделать иммутабельные строки, что само по себе очень хорошо. И, кстати, теряя в переводе массив байт <-> строка, мы получаем очень дешевую и безопасную операцию substring, по сравнению с традиционными c-строками.
На самом деле, если внимательно смотреть на профайлер среднего приложения, то потери производительности именно на этом моменте обычно и в микроскоп не видно(а если видно, то всегда можно соптимизировать). Выделение памяти и сборка молодого поколения мусора, как и блочное копирование — операции не такие уж тяжелые.

M>>Нет, неверно. Синий экран смерти помнишь? Видать, писали такие вот идиоты. Что-то нехватка памяти не привела к тому, что BSOD'а не было, а продукт никто не видел.

PD>Я думаю, что все же там было что-то иное. Простой нехваткой памяти в 3 кольце BSOD не сотворишь. Или там была ошибка в ядре. Но от ошибок никто не застрахован.

Без разницы. А выделенное — ключевое.

M>>В общем, не надо рассказывать сказки про то, как ограниченные ресурсы моментально делают из программистов безгрешных гениев — тошнит уже

PD>А этого я и не утверждал. Просто тех, кто писать не умеет, нехватка памяти приводит в ступор и они переквалифицируются в управдомы

Не надо рассказывать эти басни.

Здравствуйте, Mamut, Вы писали:

PD>>Я думаю, что все же там было что-то иное. Простой нехваткой памяти в 3 кольце BSOD не сотворишь. Или там была ошибка в ядре. Но от ошибок никто не застрахован.

M>Без разницы. А выделенное — ключевое.

Ну уж нет. Ядро Windows писали грамотные специалисты. Ну допустили ошибку, и что ? Ты их никогда не допускал ? Не надо из того факта, что был BSOD где-то когда-то, делать далеко идущие выводы.

M>>>В общем, не надо рассказывать сказки про то, как ограниченные ресурсы моментально делают из программистов безгрешных гениев — тошнит уже

PD>>А этого я и не утверждал. Просто тех, кто писать не умеет, нехватка памяти приводит в ступор и они переквалифицируются в управдомы

M>Не надо рассказывать эти басни.

Оставь себе и сказки, и басни. В качестве аргумента они не годятся.
А по существу — дай сейчас написать кому-нибудь компилятор с того же Паскаля да чтобы работал на 1 Мбайте памяти, и результат очевиден : напишут те, кто умеет работать, а все остальные просто ничего не сделают.