Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+135
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;
}
Из http://habrahabr.ru/post/149877/
И коммент афтора - "Здесь всё просто: пока не дойдём до пустой строки, прибавляем к счётчику строк единичку. Функция возвращает количество строк."
Запостил: 
phoenixx,
20 Августа 2012
Follow us!
Правильней было бы вычитывать поблочно, подсчитывая кол-во \r или \n.
И, как по мне, правильным подходом было бы вычитывание блоков byte, проверка есть ли в них \r либо \n, заполнение новыми данными того же блока, проверка, и так по кругу.
File.ReadAllLines вернёт массив строк - string[]. Т. е. в памяти будет держаться весь файл.
Нужно использовать File.ReadLines - это вернёт IEnumerable<string>. Т. е. чтение будет ленивое, в памяти будет держаться всего по одной строке.
Во втором случае памяти хватит гарантированно - сработает GC и удалит ставшие ненужными строки. А удаление короткоживущего объекта очень дёшево.
http://govnokod.ru/11619#comment151397
Эх. Любители "оптимизаций" для GC. Смешнее только пыхапешник экономящий на спичках.
Кстати алок объекта в современных VM - 10 машинных инструкций, что совсем немного.
P.S. GC для мелких короткоживущих объектов крайне эффективен. Чуть-чуть медленнее стековых переменных ;) Фишка в том, что new это тупой инкремент с проверкой оставшейся памяти, а при сборке мусора копирующий GC будет "спасать" только живые объекты, а кучи погибших строчек он даже не заметит.
Замерял разницу в памяти, и время выполнения, каждый тест выполнялся отдельно от остальных.
Мой вариант с буфером - 556kb и 2994ms
Оригинал - 4820kb и 1087ms
Вариант с ReadLines(some).Count() - 5496kb и 1113ms
Вариант с буфером менее использует память, но и самый медленный. Походу для большинства задач ReadLines(..) должно хватить с головой.
Более того это самый короткий вариант.
ReadLine() уже читает поток пока не встретит Environment.NewLine
Да и зачем, если можно сделать это используя один набор byte[]
reader.Read будет брать следующий символ из буфера стримридера, либо будет сам вычитывать следующий блок. Покрайней мере этот способ не выжирает так сильно память, как оригинал.
Да, здесь могут быть еще нюансы, если в файле идут только \r разделители, и два переноса идут подряд, то тогда подсчет будет неправильным. Но ведь это только сэмпл.
прототип? но это наш продукт?
> пример как правильней считать переносы в файле
> в отличии от оригинала
Вот в оригинале-то пока что правильней (что и ваш тест выше подтвердил)...
А вот в сравнении с ReadLines - наверно. Но я бы сказал это зависит от задачи. Если нужно перебирать N гиговые текстовые файлы, и это может быть узким местом, то что мой вариант, что ReadLines могут не подойти.
Плюсую вот за это.
Имхо, такую портянку кода следует писать лишь в том случае, если профайлер покажет, что затык именно в нагрузке на сборщик мусора. Уверен на 99,99% что проблем с этим не будет. Поэтому лучше потратить время на оптимизацию действительно проблемного куска кода (по результатам профайлера).
Ну наконец-то здравое мнение ИТТ.
>>Нужно использовать File.ReadLines - это вернёт IEnumerable<string>.
Да я так и хотел. Какой же LINQ без IEnumerable?
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 ПИТУХИ
КОКОКОКОКОКОКО
Пользователь krypt получает предупреждение согласно правил:
Цитата:
Цитата:
Пользователь krypt получает предупреждение согласно правил:
Имхо, "согласно правил" как-то не по русски звучит. Согласно правилам, или в соответствии с правилами.
Тоже как-то не по-русски
Самокритичненько Главпетух, наджаву, 3.14159265дар!
Кстати посмотрев на высеры до-диезников я понимаю почему в жабе ввели крайне неудобные для нормальных людей checked exceptions.
Да и вообще в мире C# так не принято считать. Есть же LINQ.
у well-known exceptions есть как плюсы так и минусы, ты их перечислил, дай посчитаю... ровно ноль.
Замечание про незакрытый поток - тебе плюс.
А вообще, Linq и AsParallel - устаревающие мемы. На подходе C#5 и .Net4.5 - встречаем async и await! (Ой, чую, говна с ними будет написано столько...)
Вот тут можно почитать - http://msdn.microsoft.com/ru-ru/magazine/hh456403.aspx
PS. На практике не использовал и могу ошибаться в деталях.
> Старые дотнетчики привыкли обходиться без него.
Старые диезники таких ошибок не делают
И зачем пытаться написать кривой велосипед, если уже за тебя подумали и всё сделали? Тем более если не умеешь делать велосипеды лучше, чем те что есть?
Та может и не будет. Там думать надо.
И что же это получается AssParallel не дает хорошей, истинной асинхронности и параллельности, раз asyncи всякие мудрят?
PS. Почитал подробней. Не в жаве такого нету. Но непонятно зачем они мутят? Итак язык сложный стал.
Параллельность даёт хорошую. Применять легко. Отчасти, поэтому его могут пихать куда попало (в реальности этим только на ГК грешат).
Асинхронность - другое дело. Но с использованием async/await это становится также легко. Поэтому, боюсь, могут начать применять не там, где это реально нужно.
Может с F# знаком? В F# такое существует давно. Синтаксис, конечно, другой, но суть та же.
В двух словах это очень сильно упрощает написание асинхронного кода. В разы! Достаточно понимать работу Task. Впрочем, с использованием тасков с ContinueWith и так сильно упрощается код даже без суперновых фич.
Пока нет онлайн-компиляторов C#5, поэтому не получится привести пример кода с выполнением.
Если кто интересуется реально, то советую книгу C# 5.0 in a Nutshell (на английском, найти и скачать - легко). В ней асинхронность хорошо описана.
Для поверхностного знакомства, например, это: http://nesteruk.wordpress.com/2010/10/31/async-await-csharp5/
Старая школа:
Школа поновее
LINQ-школa
Писать можно как угодно, главное делать это с умом.
А вообще, Linq и AsParallel - устаревающие мемы.
Кастую в тред @moderatorа, согласно правилу 1.9.0 'Надругательство над святынями'.
не будет каждый раз создавать новый string