[yurfed]

уж точно никак не ускорит данная программа. »

Впихнуть невпихуемо - расскажите остальным.
Ну или в принципе все варианты рабочие.
Другого решения у меня нет.
Может кто и подскажет.
Быстрое решение я вам предложил.

эти текстовые файлы, потом удалить дубли из них, и объединить в 1 файл. »

Это совсем другая тема

[bredych]

Если даже и так, то каким образом мне создать базу данных, если у меня в архиве, в разных папках эти txt разбросаны? Мне в любом случае сначала разархивировать архив, потом найти эти текстовые файлы, потом удалить дубли из них, и объединить в 1 файл. »

а зачем?
Если имеет значение только содержание, то алгоритм такой:
открывается файл, строки из него переносятся в базу, последняя - закрывается, открывается следующий и т.д.
Насрать, если будут дубли.
Просто в базе сортируете значения (напр, по возрастанию, не суть), далее простейший цикл "если строка №+1 = строке №, удалить строку №+1".

Профит. Далее играйтесь с этим как угодно.

Про RAM-диски слышали? Я на них намёк веду. »

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

[quesd]

@bredych Вы мне сейчас рассказали работу как сделать свой антипаблик с помощью базы данных. Меня такой вариант не устраивает. У меня уже есть самописный софт для таких задач.
Мне просто нужно решение, которое как можно быстрее разархивирует архив, находит файлы, удаляет дубликатные файлы, копирует миллион файлов в другую одну папку, объединяет всё в 1 файл.
И уже этот 1 файл у меня воспринимает и парсит определённые данные. Если что, я создам новую тему, какие ещё есть методы чтобы быстрее парсить данные. Это тоже мне нужно.
Но на данный момент, в приоритете у меня скорее это

искать сапоги скороходы, чтоб быстрее носить воду вёдрами. »

[dmitryst]

какие ещё есть методы чтобы быстрее парсить данные »

парсить большой файл в целом, тяжелее, чем множество мелких. Вполне может быть, что упрётесь в какие-нибудь ограничения. Как вообще парсить собираетесь, хотя бы ЯП какой?

[YuS_2]

парсить большой файл в целом, тяжелее, чем множество мелких. »

Скажем так: например, число ПИ, записанное в текстовый файл с точностью до 2 миллиардов знаков (по сути, это текстовый файл около 2Гб), в поиске 8 символов, парсится за 4523,2777 миллисекунд до смещения 1816743898 - это тяжелый парсинг?

какие ещё есть методы чтобы быстрее парсить данные. »

С помощью потокового чтения, например парсинг можно ускорить, но в Вашем случае вопрос немного в другом... всё будет упираться в архивацию, копирование множества файлов, а также их последовательное открытие-закрытие (чтение/запись)... при указываемых Вами количествах таких файлов... хмм, даже не знаю, с помощью чего тут можно ускорить процесс...
Ну и собственно, судя по Вашему запросу, задача одноразовая? Тут проще таки воспользоваться какими-то готовыми решениями, пусть даже с немаленькими временными затратами...

[quesd]

задача одноразовая? »

В каком плане? Мне очень часто нужно будет сортировать файлы. Сегодня одни файлы, завтра другие и т.д. Тогда ответ нет.
Если же в плане, закинуть архив, распаковать, отсортировать файлы и удалить архив и все эти файлы - то ответ да. Здесь не нужно хранить будет файлы, т.к я один отсортированный файл скачаю к себе на комп.

Тут проще таки воспользоваться какими-то готовыми решениями »

Например?

число ПИ »

Было бы всё так просто)) Цифры очень легко сортируются, парсятся и т.д. Но если же в текстовом документе спец. символы, буквы на разных языках, цифры - то тут уже гораздо дольше времени уйдёт на сортировку.

парсить большой файл в целом, тяжелее, чем множество мелких »

Про что идёт речь? Если про единичный файл - то да, здесь соглашусь. В одном мелком файле, очень мало данных, по сравнению, если все эти мелкие файлы объединить в один большой, и его уже парсить на определённые данные.
Если же речь идёт про архивирование/копирование/перетаскивание - то тут наоборот всё. Один большой файл займёт на все эти операции очень мало времени, по сравнению с миллионами мелких файлов, которые могут растянуться на очень много часов. Ну по крайней мере, это так работает на NTFS. В других ФС я не тестил. Но очень хотелось бы протестировать! Но не знаю с какой ФС начать, и какую выбрать, чтобы гарантированно были максимальные скорости на мелкие файлы!!! Как раз по этому вы и видите этот топик - чтобы ответить на этот вопрос. Ну точнее, один из моих вопросов.

Как вообще парсить собираетесь, хотя бы ЯП какой? »

Сейчас у меня есть самописный сортировщик. Делалось на заказ. Написан на C# буквально на коленке. Он требует большой доработки и оптимизации и ускорении работы. Но сейчас вообще нет времени тестировать этот сортировщик на наличие багов, оптимизацию, делать замеры и т.д. По этому и ищу более лёгкие, быстрые, проверенные решения на данную тему!

[YuS_2]

Мне очень часто нужно будет сортировать файлы. Сегодня одни файлы, завтра другие и т.д. Тогда ответ нет. »

Ну, то бишь задача периодическая? Тогда имеет смысл её автоматизировать... но чтобы её автоматизировать, необходимы не общие пронумерованные вводные, а подробная формулировка, причем с примерами данных...

Например? »

У меня нет примеров... я ведь не понимаю до сих пор смысл задачи...

Цифры очень легко сортируются, парсятся и т.д. Но если же в текстовом документе спец. символы, буквы на разных языках, цифры - то тут уже гораздо дольше времени уйдёт на сортировку. »

Конечно, скорость будет зависеть от объемов данных и от количества файлов (особенно от количества), ну и от, собственно, действий, которые необходимо выполнить с найденными данными, но содержимое, то бишь тип символов, на сам парсинг сильно влиять не будет, для парсера нет разницы какие символы парсить.

[bredych]

Мне очень часто нужно будет сортировать файлы. Сегодня одни файлы, завтра другие и т.д. »

+

Если же в плане, закинуть архив, распаковать, отсортировать файлы и удалить архив и все эти файлы - то ответ да. »

противоречие.
Или однократная задача, или регулярная. И то и другое сразу - не бывает.

[Jula0071]

более 1 миллиона текстовых файлов, весом от 1 до 500 КБ. »

Уж на NTFS + SSD на pcie 4.0 это было примерно полдня (8-10 часов). »

Предположим, средний размер 250 КБ, миллион таких файлов это довольно скромные 250 гигабайт... не то что бы с таким объёмом данных легко работать, но ничего особенного... у вас лыжи не едут. И смазывай их или не смазывай - в смысле переходи на супер-пупер быстрый сторедж - они быстрее не поедут. Нужно пересаживаться с лыж на то-то более подходящее.

[sputnikk]

SSD на pcie 4.0 »

Какая модель? Если с 2-канальным контроллером и без буфера DDR, то будет чуть быстрее SATA