Необходимо проанализировать большие текстовые файлы

@dj-12l · Регистрация: 22.02.2016

Студворк — интернет-сервис помощи студентам

Добрый день.
Подскажите, как лучше реализовать задачу, по анализу всех файлов в папке и подпапках с регулярными выражениями.
Насколько я понял есть 3 способа:
1. Воспользоваться LINQ, но в нем нельзя использовать регулярные выражения.
2. Использовать regex, а потом match.success построчно.
3. Использовать contains.

т.к. файлы могут быть большого размера, доходя до 2 Гб или больше, то необходимо 1. использовать using или AsParallel в linq.
но встает вопрос в том, что если производить вывод найденных ошибок, то зависает основной поток, хоть пробовал с using.

Хочу сделать:
1. Найти все файлы в каталоге и подкаталогах по маске (может быть .log и .txt и тд).
2. Проанализировать все файлы через регулярные выражения, которые задаются во время работы программы (то есть не compiler).
3. если в файле найдена ошибка, есть совпадение, то 1. скопировать исходный файл, где ошибка и 2. в отдельный файл собрать все ошибки.
4. опциально выводить ошибки в реальном времени, по мере нахождения. Для этого не должен блокироваться основной поток.

Пробовал using, но есть зависание textbox, долго разбирается и полагаю это не многопоточный анализ или не паралельное.
Есть идеи, как реализовать быстрый анализ больших текстовых файлов?
P.S пока реализовываю на WinForm, но думаю и из консольного примера переведу на form

@Usaga · 25.01.2021, 12:01

Сообщение от dj-12l

Пробовал using

Это ключевое слово вы как связали с многопоточностью и чтением текста?)

Вообще, не видя кода не можно дать дельный совет. Вполне может статься, что чтение в один поток будет достаточно быстрым.

Ну и чтобы UI не зависал нужно тяжёлые операции производить в отдельном потоке.

@dj-12l · 25.01.2021, 13:54 **[ТС]**

Сообщение от Usaga

е видя кода

На данный момент, есть только это:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
       private string ConvertRegex()
        {   // конвертация введенных регулярных выражений в TextBox. 
            string IdOrder = Convert.ToString(TextBox1.Text.Trim());
            string RegexTextbox = IdOrder.Replace("\r\n", "");
            return RegexTextbox;
        }
 
 
        void Outputtext(string path)
        {
            string line;
 
            //Получение файлов из пути вписанного в textbox
            foreach (string file in Directory.EnumerateFiles(path, "*.*", SearchOption.AllDirectories))
            {
                string regextemp = ConvertRegex();
                Regex regex = new Regex(regextemp);
 
                //using для независания основного потока. 
                using (StreamReader reader = new StreamReader(Path.GetFullPath(file))) {
                    while ((line = reader.ReadLine()) != null)
                    {
                        Match match regex.Match(line);
                        if (match.Success)
                        {
                            //тут что делать со строкой. например вывожу:
                            textbox2.Text += line;
 
                        }
                    }
                }
            }
        }

Следовательно тут я не реализовал запись в файл, проверку на ошибки. Застрял на нормальном чтении файлов.

@JustinTime · 25.01.2021, 14:15

Сообщение от dj-12l

//using для независания основного потока.

это где вам такое сказали? по моей информации using вызывает Dispose для reader.

@Usaga · 25.01.2021, 15:21

Сообщение от dj-12l

string IdOrder = Convert.ToString(TextBox1.Text.Trim());

Строка, которую возвращает Trim() не достаточно строковая оказалась?)

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

randok · 25.01.2021, 16:25

Сообщение от Usaga

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

Скорее будет наоборот, если диск не заточен под работу с многопоточкой. Хотя даже если дисковая подсистема рассчитана на подобную нагрузку, все равно можно ее замучить. Лучше читать в один поток.

Сообщение от dj-12l

//using для независания основного потока.

В c# using это либо директива, либо оператор. Директива используется для пространств имен, например using System;, или как директива с псевдонимом, например using My = System.Console; и потом можно написать My.WriteLine("hello world");. Оператор using используется для правильного использования объектов, реализующих IDisposable. То есть вместо StreamReader reader = new StreamReader и потом reader.Close() вы оборачиваете ридер в юзинг. Для "независания основного потока" используйте async/await и Invoke для передачи данных в основной поток, например в текстбокс.
По поводу общего быстродействия - регулярки намного тяжелее выполняются, если есть возможность обойтись без них, то лучше без них, особенно на таком огромном количестве данных. Либо почитайте про кэширование регулярок https://docs.microsoft.com/ru-... xpressions
Можно подготовить какие-то определенные регулярки и скомпилировать их в сборку, типа:

C#
1
Regex regex1 = new Regex("[^a-zA-Z&-]+", RegexOptions.Compiled);

@Usaga · 25.01.2021, 16:29

Сообщение от randok

Скорее будет наоборот, если диск не заточен под работу с многопоточкой. Хотя даже если дисковая подсистема рассчитана на подобную нагрузку, все равно можно ее замучить. Лучше читать в один поток.

На самом деле чтение в один поток не отменяет многопоточности при поиске подстроки. Можно реализовать Producer-Consumer: читаем построчно в один поток и раскидываем по "воркерам" не ожидая ответа. Вот это будет достаточно производительно, без чрезмерной нагрузки на накопитель.

randok · 25.01.2021, 16:32

Сообщение от Usaga

Можно реализовать Producer-Consumer: читаем построчно в один поток и раскидываем по "воркерам" не ожидая ответа.

Да, это вариант, но скорее всего все как обычно упрется в диск и все будут его ждать. Либо в воркерах должно что-то такое крутиться, что сильно превышает чтение с диска по времени выполнения, тогда будет смысл.

Новые блоги и статьи Все статьи Все блоги /
Отображение реквизитов в документе по условию и контроль их заполнения Maks 04.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеСпецтехники", разработанного в конфигурации КА2. Данный документ берёт данные из другого нетипового документа. . .	Фото всей Земли с борта корабля Orion миссии Artemis II kumehtar 04.04.2026 Это первое подобное фото сделанное человеком за 50 лет. Снимок называют новым вариантом легендарной фотографии «The Blue Marble» 1972 года, сделанной с борта корабля «Аполлон-17». Новое фото. . .	Вывод диалогового окна перед закрытием, если документ не проведён Maks 04.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать программный контроль на предмет проведения документа. . .	Программный контроль заполнения реквизита табличной части документа Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать контроль заполнения реквизита "ПричинаСписания". . .
wmic не является внутренней или внешней командой Maks 02.04.2026 Решение: DISM / Online / Add-Capability / CapabilityName:WMIC~~~~ Отсюда: https:/ / winitpro. ru/ index. php/ 2025/ 02/ 14/ komanda-wmic-ne-naydena/	Программная установка даты и запрет ее изменения Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: при создании документов установить период списания автоматически. . .	Вывод данных в справочнике через динамический список Maks 01.04.2026 Реализация из решения ниже выполнена на примере нетипового справочника "Спецтехника" разработанного в конфигурации КА2. Задача: вывести данные из ТЧ нетипового документа. . .	Программное заполнения текстового поля в реквизите формы документа Maks 01.04.2026 Алгоритм из решения ниже реализован на нетиповом документе "ВыдачаОборудованияНаСпецтехнику" разработанного в конфигурации КА2, в дополнении к предыдущему решению. На форме документа создается. . .

@dj-12l 85 / 1 / 0 Регистрация: 22.02.2016 Сообщений: 103

	Необходимо проанализировать большие текстовые файлы 25.01.2021, 11:51. Показов 1278. Ответов 7 Метки нет (Все метки) Добрый день. Подскажите, как лучше реализовать задачу, по анализу всех файлов в папке и подпапках с регулярными выражениями. Насколько я понял есть 3 способа: 1. Воспользоваться LINQ, но в нем нельзя использовать регулярные выражения. 2. Использовать regex, а потом match.success построчно. 3. Использовать contains. т.к. файлы могут быть большого размера, доходя до 2 Гб или больше, то необходимо 1. использовать using или AsParallel в linq. но встает вопрос в том, что если производить вывод найденных ошибок, то зависает основной поток, хоть пробовал с using. Хочу сделать: 1. Найти все файлы в каталоге и подкаталогах по маске (может быть .log и .txt и тд). 2. Проанализировать все файлы через регулярные выражения, которые задаются во время работы программы (то есть не compiler). 3. если в файле найдена ошибка, есть совпадение, то 1. скопировать исходный файл, где ошибка и 2. в отдельный файл собрать все ошибки. 4. опциально выводить ошибки в реальном времени, по мере нахождения. Для этого не должен блокироваться основной поток. Пробовал using, но есть зависание textbox, долго разбирается и полагаю это не многопоточный анализ или не паралельное. Есть идеи, как реализовать быстрый анализ больших текстовых файлов? P.S пока реализовываю на WinForm, но думаю и из консольного примера переведу на form 0