- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
public int getFileRowsCount(string pathToFile)
{
System.IO.TextReader streamReader = new System.IO.StreamReader(pathToFile);
int rowsCounter = 0;
while ((streamReader.ReadLine()) != null)
{
rowsCounter++;
}
streamReader.Close();
return rowsCounter;
}
HaskellGovno 20.08.2012 13:19 # +1
phoenixx 20.08.2012 13:35 # −3
Правильней было бы вычитывать поблочно, подсчитывая кол-во \r или \n.
phoenixx 20.08.2012 13:42 # −3
И, как по мне, правильным подходом было бы вычитывание блоков byte, проверка есть ли в них \r либо \n, заполнение новыми данными того же блока, проверка, и так по кругу.
sayidandrtfm 20.08.2012 13:48 # +2
3.14159265 20.08.2012 13:55 # +4
abatishchev 20.08.2012 13:57 # 0
rat4 20.08.2012 14:24 # +4
koodeer 20.08.2012 17:24 # +2
File.ReadAllLines вернёт массив строк - string[]. Т. е. в памяти будет держаться весь файл.
Нужно использовать File.ReadLines - это вернёт IEnumerable<string>. Т. е. чтение будет ленивое, в памяти будет держаться всего по одной строке.
phoenixx 20.08.2012 17:29 # −2
koodeer 20.08.2012 17:54 # +2
Во втором случае памяти хватит гарантированно - сработает GC и удалит ставшие ненужными строки. А удаление короткоживущего объекта очень дёшево.
phoenixx 20.08.2012 19:31 # 0
3.14159265 20.08.2012 19:34 # 0
http://govnokod.ru/11619#comment151397
Эх. Любители "оптимизаций" для GC. Смешнее только пыхапешник экономящий на спичках.
Кстати алок объекта в современных VM - 10 машинных инструкций, что совсем немного.
phoenixx 20.08.2012 19:38 # 0
phoenixx 20.08.2012 17:30 # −2
bormand 20.08.2012 18:00 # +3
P.S. GC для мелких короткоживущих объектов крайне эффективен. Чуть-чуть медленнее стековых переменных ;) Фишка в том, что new это тупой инкремент с проверкой оставшейся памяти, а при сборке мусора копирующий GC будет "спасать" только живые объекты, а кучи погибших строчек он даже не заметит.
phoenixx 20.08.2012 18:58 # +2
Замерял разницу в памяти, и время выполнения, каждый тест выполнялся отдельно от остальных.
Мой вариант с буфером - 556kb и 2994ms
Оригинал - 4820kb и 1087ms
Вариант с ReadLines(some).Count() - 5496kb и 1113ms
Вариант с буфером менее использует память, но и самый медленный. Походу для большинства задач ReadLines(..) должно хватить с головой.
HaskellGovno 20.08.2012 22:13 # 0
bormand 20.08.2012 22:14 # +1
HaskellGovno 20.08.2012 22:17 # 0
Более того это самый короткий вариант.
abatishchev 20.08.2012 14:01 # −2
ReadLine() уже читает поток пока не встретит Environment.NewLine
phoenixx 20.08.2012 14:03 # 0
Да и зачем, если можно сделать это используя один набор byte[]
abatishchev 20.08.2012 14:15 # 0
phoenixx 20.08.2012 14:16 # 0
abatishchev 20.08.2012 14:56 # 0
phoenixx 20.08.2012 15:27 # +2
reader.Read будет брать следующий символ из буфера стримридера, либо будет сам вычитывать следующий блок. Покрайней мере этот способ не выжирает так сильно память, как оригинал.
Да, здесь могут быть еще нюансы, если в файле идут только \r разделители, и два переноса идут подряд, то тогда подсчет будет неправильным. Но ведь это только сэмпл.
defecate-plusplus 20.08.2012 15:30 # +3
phoenixx 20.08.2012 15:31 # 0
defecate-plusplus 20.08.2012 15:33 # 0
прототип? но это наш продукт?
phoenixx 20.08.2012 15:36 # 0
defecate-plusplus 20.08.2012 15:42 # +1
vistefan 20.08.2012 19:25 # 0
> пример как правильней считать переносы в файле
> в отличии от оригинала
Вот в оригинале-то пока что правильней (что и ваш тест выше подтвердил)...
phoenixx 20.08.2012 19:28 # 0
А вот в сравнении с ReadLines - наверно. Но я бы сказал это зависит от задачи. Если нужно перебирать N гиговые текстовые файлы, и это может быть узким местом, то что мой вариант, что ReadLines могут не подойти.
3.14159265 20.08.2012 15:31 # +6
Плюсую вот за это.
koodeer 20.08.2012 17:36 # +4
Имхо, такую портянку кода следует писать лишь в том случае, если профайлер покажет, что затык именно в нагрузке на сборщик мусора. Уверен на 99,99% что проблем с этим не будет. Поэтому лучше потратить время на оптимизацию действительно проблемного куска кода (по результатам профайлера).
3.14159265 20.08.2012 19:20 # 0
Ну наконец-то здравое мнение ИТТ.
>>Нужно использовать File.ReadLines - это вернёт IEnumerable<string>.
Да я так и хотел. Какой же LINQ без IEnumerable?
phoenixx 20.08.2012 14:06 # 0
3.14159265 20.08.2012 13:40 # +5
StreamЯeader САМ НЕ ЗАКРОЕТСЯ
ЗАКРОЙ ЕГО, ЗАКРОЙ ЕГО ЕЩЕ РАЗ
ЗАЧЕМ МНЕ НУЖЕН FINALLY, У МЕНЯ НЕТ ВРЕМЕНИ ЧТОБЫ ПИСАТЬ ЕГО
ЛУЧШЕ ЕЩЕ РАЗ ЗАКРЫТЬ StreamЯeader
Я ЗАКРЫВАЮ StreamЯeader ПО 3 РАЗА В ДЕНЬ
КАЖДЫЙ ЭКСЕПШЕН И ОН ЗАНИМАЕТ ЦЕННЫЕ РЕСУРСЫ
Я ЖИВУ АКТИВНОЙ И ПОЛНОЦЕННОЙ ЖИЗНЬЮ
Я УСПЕШЕН И ПОЭТОМУ ЦЕЛЫЙ ДЕНЬ ПИШУ ГОВНО
А ПОСЛЕ ЭТОГО ЗАКРЫВАЮ StreamЯeader
ТУПЫЕ ЖАВИСТЫ ОДЕРЖИМЫ CHECKED EXCEPTIONАМИ
А Я СВОБОДНЫЙ ОТ ЗАДРОТСТВО ЧЕЛОВЕК
СКОЧАТЬ БЕЗПЛАТНО РУССКАЯ ВИЗУАЛ СТУДИЯ
PDF СИШАРП ЗА 21 ДЕНЬ
ЛУЧШЕ Я ЗАКРОЮ ЕЩЕ РАЗ StreamЯeader
СТАБИЛЬНОСТЬ НЕ НУЖНА
Я НЕ ЗАКРЫВАЛ StreamЯeader НЕДЕЛЮ
ПОЙДУ ЗАКРОЮ
В С# ВСЕ ПРОСТО И ПОНЯТНО
ОШИБКА STOP 0x0000000A. НЕПОНЯТНО ПОЧЕМУ ОНО ВЫЛЕЗЛО
ПРИШЛО ВРЕМЯ ЗАКРЫВАТЬ StreamЯeader
ККОКОКОКОКОКОКО
C#.NET LINQ ПИТУХИ
КОКОКОКОКОКОКО
phoenixx 20.08.2012 13:43 # +3
krypt 20.08.2012 13:46 # +4
moderator 20.08.2012 16:52 # +5
Пользователь krypt получает предупреждение согласно правил:
Цитата:
eth0 20.08.2012 16:57 # 0
krypt 20.08.2012 17:28 # 0
vistefan 20.08.2012 19:31 # 0
Цитата:
Пользователь krypt получает предупреждение согласно правил:
Имхо, "согласно правил" как-то не по русски звучит. Согласно правилам, или в соответствии с правилами.
absolut 20.08.2012 19:47 # +2
Тоже как-то не по-русски
3.14159265 06.10.2015 14:16 # +1
3_14dar 10.10.2015 06:07 # 0
Самокритичненько Главпетух, наджаву, 3.14159265дар!
3_14dar 06.10.2015 15:02 # 0
3.14159265 20.08.2012 13:31 # 0
Кстати посмотрев на высеры до-диезников я понимаю почему в жабе ввели крайне неудобные для нормальных людей checked exceptions.
Да и вообще в мире C# так не принято считать. Есть же LINQ.
abatishchev 20.08.2012 14:03 # 0
у well-known exceptions есть как плюсы так и минусы, ты их перечислил, дай посчитаю... ровно ноль.
3.14159265 20.08.2012 15:32 # +5
koodeer 20.08.2012 17:32 # −1
Замечание про незакрытый поток - тебе плюс.
А вообще, Linq и AsParallel - устаревающие мемы. На подходе C#5 и .Net4.5 - встречаем async и await! (Ой, чую, говна с ними будет написано столько...)
krypt 20.08.2012 17:37 # +2
phoenixx 20.08.2012 19:05 # 0
Вот тут можно почитать - http://msdn.microsoft.com/ru-ru/magazine/hh456403.aspx
PS. На практике не использовал и могу ошибаться в деталях.
3.14159265 20.08.2012 19:25 # 0
> Старые дотнетчики привыкли обходиться без него.
Старые диезники таких ошибок не делают
И зачем пытаться написать кривой велосипед, если уже за тебя подумали и всё сделали? Тем более если не умеешь делать велосипеды лучше, чем те что есть?
3.14159265 20.08.2012 19:36 # 0
Та может и не будет. Там думать надо.
И что же это получается AssParallel не дает хорошей, истинной асинхронности и параллельности, раз asyncи всякие мудрят?
PS. Почитал подробней. Не в жаве такого нету. Но непонятно зачем они мутят? Итак язык сложный стал.
koodeer 20.08.2012 20:37 # 0
Параллельность даёт хорошую. Применять легко. Отчасти, поэтому его могут пихать куда попало (в реальности этим только на ГК грешат).
Асинхронность - другое дело. Но с использованием async/await это становится также легко. Поэтому, боюсь, могут начать применять не там, где это реально нужно.
koodeer 20.08.2012 20:34 # 0
Может с F# знаком? В F# такое существует давно. Синтаксис, конечно, другой, но суть та же.
В двух словах это очень сильно упрощает написание асинхронного кода. В разы! Достаточно понимать работу Task. Впрочем, с использованием тасков с ContinueWith и так сильно упрощается код даже без суперновых фич.
Пока нет онлайн-компиляторов C#5, поэтому не получится привести пример кода с выполнением.
Если кто интересуется реально, то советую книгу C# 5.0 in a Nutshell (на английском, найти и скачать - легко). В ней асинхронность хорошо описана.
Для поверхностного знакомства, например, это: http://nesteruk.wordpress.com/2010/10/31/async-await-csharp5/
3.14159265 20.08.2012 19:27 # +4
Старая школа:
Школа поновее
LINQ-школa
Писать можно как угодно, главное делать это с умом.
vistefan 20.08.2012 19:36 # +6
А вообще, Linq и AsParallel - устаревающие мемы.
Кастую в тред @moderatorа, согласно правилу 1.9.0 'Надругательство над святынями'.
psycho-coder 22.08.2012 16:23 # −6
bormand 22.08.2012 16:55 # +9
guest 06.10.2015 07:14 # 0
не будет каждый раз создавать новый string