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

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

S>> Тогда проще модифицировать StreamReader.readLine, но обрабатывать байты а не чары с использованием BitArray.
KS>Про буфер ясно. А вот чем тут поможет BitArray и как его заюзать — это не ясно.
KS>(И, да, я знаю что такое BitArray.)
BitArray это аналог дельфевого сета. Данные хранятся побитово То есть
установив в True
То

BA=new BitArray(246);// количество для байта
Set(byte)',',true);
Set((byte)'/r',true);
Set((byte)'/n',true);

и вычислив, что текущий символ не является символом разделителем просто увеличиваем счетчик

if (!BA[текущийбайт]) текущаяПозиция++;
 else
{ 
отрабатываем символы разделители.

}

Так как в основном символы не разделители, мы экономим на сравнении. Кстати стандартная техника в Delphi.
Так как для Set выполняется одна ассемблерная инструкция

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

S>Здравствуйте, Kore Sar, Вы писали:

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

S>>> Тогда проще модифицировать StreamReader.readLine, но обрабатывать байты а не чары с использованием BitArray.
KS>>Про буфер ясно. А вот чем тут поможет BitArray и как его заюзать — это не ясно.
KS>>(И, да, я знаю что такое BitArray.)
S> BitArray это аналог дельфевого сета. Данные хранятся побитово То есть
S>установив в True
S>То

S>

S>BA=new BitArray(246);// количество для байта
S>Set(byte)',',true);
S>Set((byte)'/r',true);
S>Set((byte)'/n',true);
S>

S>и вычислив, что текущий символ не является символом разделителем просто увеличиваем счетчик


S>

S>if (!BA[текущийбайт]) текущаяПозиция++;
S> else
S>{ 
S>отрабатываем символы разделители.

S>}
S>

S> Так как в основном символы не разделители, мы экономим на сравнении. Кстати стандартная техника в Delphi.
S>Так как для Set выполняется одна ассемблерная инструкция


Что-то на этот раз у вас плохо получилось объяснить. Я ничего не понял.
И код совершенно непонятен.

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

Создаешь битовый массив размером макс бай+1
В него помечаешь в труе для кодов символов разделителей
S>>

S>>BA=new BitArray(246);// количество для байта
S>>Set(byte)',',true);
S>>Set((byte)'/r',true);
S>>Set((byte)'/n',true);
S>>

S>>и вычислив, что текущий символ не является символом разделителем просто увеличиваем счетчик


S>>

S>>if (!BA[текущийбайт]) текущаяПозиция++;
S>> else
S>>{ 
S>>отрабатываем символы разделители.

S>>}
S>>

S>> Так как в основном символы не разделители, мы экономим на сравнении. Кстати стандартная техника в Delphi.
S>>Так как для Set выполняется одна ассемблерная инструкция
Если текущий символ в битовом массиве установлен в фальш, то это не символ разделитель, поэтому увеличиваем счетчик,
иначе это разделитель выделяем новую строку, а если это конец строки то возвращаем массив строк.
На свиче если это не символ разделитель мы должны сделать три сравнения. При битовом массиве всего одно.

А>>Что вы делаете с этими данными? Если льете в базу — посмотрите в сторону bulk...
KS>Не льём. Мы их считаем. Статистика и всё такое...

Если там циферки одни.То, ИМХО, избавляться напрочь от типа string. Работать только с char. (Или вобще с байтами).Напрямую в циферки переводить.
Несколько гигабайт маленьких стрингов создать, это уже слишком. Это сотни миллионов string создается?

Если не вру, string не просто в динамической памяти создается, каждый string всегда в Хеш-таблицу заносится, при создании и хеш таблица проверяется нет ли уже такого стринга,потом заносится ....
Не скажу точно насколько это процесс может затормаживать... но както сомнительно столько string создавать

А надо то всего лишь итеративный алгоритм парсинга циферок из char[], или из byte[]
Можно и от split избавиться, даже если он и byte[] для каждой циферки создает, а не string.
Незачем динамическую память ряди этого гонять.

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

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

Свич по байту вполне возможно будет оптимизирован именно так, причем скорее всего с более оптимальным расходом памяти. Впрочем 4 сравнения не факт что будут дольше, оптимизатору обычно виднее.

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

А>>>Что вы делаете с этими данными? Если льете в базу — посмотрите в сторону bulk...
KS>>Не льём. Мы их считаем. Статистика и всё такое...

S_>Если там циферки одни.То, ИМХО, избавляться напрочь от типа string. Работать только с char. (Или вобще с байтами).Напрямую в циферки переводить.
S_>Несколько гигабайт маленьких стрингов создать, это уже слишком. Это сотни миллионов string создается?

Только ради ускорения клиентской части мы не будем переписывать серверную часть. (Хоть и хочется). Нам не дадут это сделать, слишком затратно и пользы мало.


S_>Если не вру, string не просто в динамической памяти создается, каждый string всегда в Хеш-таблицу заносится, при создании и хеш таблица проверяется нет ли уже такого стринга,потом заносится ....

Не каждый. Проверено.


S_>Не скажу точно насколько это процесс может затормаживать... но както сомнительно столько string создавать

S_>А надо то всего лишь итеративный алгоритм парсинга циферок из char[], или из byte[]
S_>Можно и от split избавиться, даже если он и byte[] для каждой циферки создает, а не string.
S_>Незачем динамическую память ряди этого гонять.

Все с этим согласны, кроме наших самых главных товарищей. Им виднее, имхо, какие задачи делать, а какие нет.


Давайте закроем уже эту тему. Я выяснил всё, что хотел.
Спасибо.

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

Z>Свич по байту вполне возможно будет оптимизирован именно так, причем скорее всего с более оптимальным расходом памяти. Впрочем 4 сравнения не факт что будут дольше, оптимизатору обычно виднее.
Возможно. Нужно сравнивать. Экономнее только хэш таблица. А BitArray 32 байта, но доступ за одну асcемблерную операцию bt.