Python-сообщество

FishHook
Даааавно уже есть

Ага и как все что делают в микрософте оно для домохозяек и в реальной работе не годится.
Винда8 64 На первом же файле получаю:
1. По сути проблемы. Если ОС 32 разряда я бы вообще сразу разбил файлы на куски по 1GB (конечно учитывая семантические границы в файлах). Трудности ведь будут не только у вашей программы, но почти во всех программах.
2. На мой взгляд проще всего написать на С динамическую библиотечку для чтения блоков данных достаточно большого размера, но до семантических границ. Я не люблю seek назад.

doza_and
Ну а если я сейчас покажу в таком же виде, что все ищется без проблем, то нам останется только письками мериться, да?

> ЗЫ. что удивительно: когда изменил размер куска с мегабайта на 32 Мб, то процесс шел медленней.

Нет в этом ничего удивительного. Регулярки ресурсоёмки и работают довольно медленно.
P.S. Желательно что-бы размер “куска” был кратен размеру блока ФС, тогда “кусок” будет читаться более быстро. Хотя в твоём случае это скорости не добавит.

FishHook
то нам останется только письками мериться

Странно что вы это так воспринимаете.
Вы имеете ввиду что там есть магические ключики регулирующие размер максимально допустимой строки?

FishHook
Ну а если я сейчас покажу в таком же виде

Ну в таком виде не надо. По уму надо привести командную строку (findstr “hello there” a.txt), загрузить файл на котором получено такое сообщение (в моем случае это 20GB). Но честно говоря поленился это делать. grep отработал на том-же файле без проблем.
Если вы приведете пример корректной работы вывод будет прежним программа работает не так как описано в документации получаемой командой /?. Т.е. она содержит ошибки. Так что вам нет смысла приводить примеры корректной работы.

Отредактировано doza_and (Дек. 18, 2016 15:37:29)

doza_and
Это я к тому, что когда речь идет о никсах, то обычно в сторону неудачного опыта летят обвинения в криворукости и неосиляторстве, а когда о виндах, то крайней остается винда. Это двойные стандарты и предвзятость в чистом виде. Обычно, холивары линух vs винда разводят пионеры в вечном стремлении померяться писюнами. Не думаю, что вам подобное мероприятие было бы интересно. Вопрос от топикстартера был “Ну и где такое в винде?”. Он получил ответ, пусть думает, что с этим делать, ведь не я же ему навязывал винду в качестве целевой оси, правда?

doza_and
семантических границ

Напоминает “у попа была собака”…

Идея интересная, но: если уже есть файл, то границу там можно найти опять таки поиском… по большому файлу… в 32 системе…

И вообще хотелось бы универсальный вариант, без дотошного знания структуры файла.

py.user.next
разбиение на огороженные части и только потом в них ищется то, что надо.

Файлы пишет не моя прога, разделение “в процессе” невозможно.

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

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

Отредактировано Iskatel (Дек. 18, 2016 16:30:18)

FishHook
Он получил ответ, пусть думает

Без обид. Натравить регулярку на длинную последовательность данных иногда бывает полезно, по этому я сразу попробовал его в деле. Согласен, инструмент есть. но у него есть и особенности которые я описал
.

Iskatel
Напоминает “у попа была собака”…

Ну не совсем. Но знание формата файла обязательно.

Iskatel
И вообще хотелось бы универсальный вариант

Думается что это грозит написанием специального варианта библиотеки для ограниченных регулярных выражений, которая позволит обрабатывать поток данных. Может ошибаюсь но похоже flex/flex++ реализуют такой вариант. можно попробовать оттуда вытащить.

doza_and
Ну не совсем. Но знание формата файла обязательно.

Давайте не будем все возводить в абсолют… Изначальное предположение, что искомое там находится неразрывными кусками вполне достаточно. Или есть возражения?

Отредактировано Iskatel (Дек. 18, 2016 17:58:57)

Iskatel
Файлы пишет не моя прога, разделение “в процессе” невозможно.

Твоя программа должна разделить на лету перед поиском. То есть программа начинает читать по блокам или по строкам и накапливает их до тех пор, пока в накопленном блоке на границе не будет двусмысленных данных. И этот накопленный блок находится в оперативной памяти (он небольшой). Потом он склеивается внутри в текст и в нём выполняется поиск. Потом он выкидывается из памяти и туда начинает накапливаться следующий блок точно таким же образом. Таким образом у тебя всё время занято немного памяти и поиск ведётся по всему файлу. Это типа смещающегося окна, про которое ты говорил, но в окне поиск выполняется и по тем данным, по которым ты уже искал, а в блоках поиск выполняется только по новым данным.

Вот смотри, ввёл ты строку поиска “.*” и что это значит? что оно должно совпасть со всеми гигабайтами файла? А как оно с ними совпадёт? Для этого она должна будет все гигабайты засунуть в оперативную память. А в оперативной памяти система сидит и никогда не известно, сколько памяти свободно (много её или мало). Вот из-за таких моментов ты это всё просто не напишешь - логически ты этого не видишь, а нюансов там таких дофига. Поэтому я тебе и говорю, сначала подучись программированию самому, чтобы хотя бы видеть алгоритм ещё до реализации. Проблема не в ограничениях системы, 32 бита в этой задаче вообще ни на что не влияют, проблема в логических подводных камнях алгоритма, которые ты не видишь, потому что программировать не умеешь (составлять алгоритмы). Что-то пытаешься написать, будто если ты начнёшь писать, то оно тогда сразу получится. Но оно не получается не из-за того, что ты не пишешь, а из-за того, что всё это неправильно придумано. Тут нельзя просто сказать “крэкс-фэкс-пэкс! программа напишись!”, тут тебе не новогодняя ёлка. Если ты не составил правильный алгоритм, то и программа не напишется.

Если grep брать (рассматривать устройство её алгоритма), там возможен поиск по регулярке, но поиск ведётся только по одной строке каждый раз, а строки не загружаются в память все сразу, а загружаются в память по одной штуке. Одна загрузилась, в ней по регулярке поискалось, потом она выкидывается и загружается следующая строка в ту же память. Таким образом память там всё время свободна, а поиск идёт.

Iskatel
Идея интересная, но: если уже есть файл, то границу там можно найти опять таки поиском… по большому файлу… в 32 системе…

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

Отредактировано py.user.next (Дек. 19, 2016 03:29:34)

py.user.next
и что это значит? что оно должно совпасть со всеми гигабайтами файла?

я же писал вначале “В данном случае я понимаю максимальную длину, того что может найтись.”, “Знаю что искомое не превышает 300 байт.”

py.user.next
То есть программа начинает читать по блокам или по строкам и накапливает их до тех пор, пока в накопленном блоке на границе…

Конкретно в тех файлах, что я искал, границу можно найти, но:

1. она сама будет длиной теже сотни байт , и опять таки проблема с ее поиском, когда “программа начинает читать по блокам или по строкам и накапливает их до тех пор…” вполне возможен вариант что граница уместится внутри блока, а возможно что и нет, будет на их стыке… О чем я собственно и писал - поиск той границы опять таки проблемка поиска…

2. это усугубляется тем, что ее, границы этой, может и не быть вовсе в пределах гигабайта - двух.

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