Программирование[8]

как в 2к19 в джаве искать файл и подстроку в файлах в директории?

https://habr.com/ru/post/437694/ вот такую штуку нашел, норм?

Files.walk(Paths.get(path))
        .filter(Files::isRegularFile)
        .forEach(
// тут делай чо хочешь с каждым файлом в зависимости от сложности и требований к производительности, в целом можно даже тот же греп вызывать в системе
)

уж лучше дать грепу фильтр пути, чем вызывать греп на каждый файл заново

он сам отлично читать и фильтровать файлы умеет

найти в пачке логов какой-то текст

aho corasick algorithm

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

60к для миддла - это прям сильно среднее по больнице, можно и больше найти ( это в Берлине ), налог 42% максимальный с гос страховкой, если ты молодой и здоровый - можешь слезть на частную и платить меньше, я за хату в 20 минутах от центра плачу 850, бонусами 20к это вообще где, у меня на ласт работе бонус был 7к, но может я бич. Жрачка в среднем дешевле чем в Киеве. Че там ещё было?

Да вова брат туалетного просто. Оба шарят во всем типа, но на деле не знают нихуя 

как тогда в германии люди делают деньги на общепите, если для конечного покупателя это выходит дешевле, чем в ебучем киеве, но при этом зарплаты работникам нужно платить несоразмерно бОльшие, не говоря уже о других статьях расходов? че-то приколямба какая-то

или просто в киеве рестораторы охуели? (вряд ли)

уж лучше дать грепу фильтр пути, чем вызывать греп на каждый файл заново

он сам отлично читать и фильтровать файлы умеет

@@Ramil

При дохуилионе файлов ебурить это стримом, ну такое, у джаста мб опыта поболее, но мне кажется способ не совсем рациональным.

Хотя, стрим с поиском можно параллелить и он это сделает максимально быстро и безопасно, т.к. это операция чтения.

Ну я про средней руки азиатские забегаловки, где поесть выходит 5-6 евро и где я обедаю/ужинаю в половине случаев, в то время как в Киеве подобного рода заведения просят примерно 7-8 евро. С другой стороны в Берлине нету бизнес ланчей как таковых, фаст фуд и всякие шавухи в Киеве тоже дешевле. Но именно среднего уровня кафешки в Киеве дороже.

 

уж лучше дать грепу фильтр пути, чем вызывать греп на каждый файл заново

он сам отлично читать и фильтровать файлы умеет

@@Ramil

При дохуилионе файлов ебурить это стримом, ну такое, у джаста мб опыта поболее, но мне кажется способ не совсем рациональным.

Хотя, стрим с поиском можно параллелить и он это сделает максимально быстро и безопасно, т.к. это операция чтения.

 

у меня достаточно опыта чтобы сказать что то что ты и кант предлагаете - это premature opt

а я, пока вы думаете над тем как это оптимально сделать, написал то что в первой ссылке гугла выдало

у челибоса задача скорее всего раз в день пробегаться по 10 файлам, каждый из коотрых пара мегобайт

а вы блять готовы тут пайплайны на хадупах проектировать

алло, это @@Just.Doit?

я же сказал, что можно так и сделать + параллелизм заюзать.

Просто если ему зададут вопрос "а что если будет 1ккккк файлов?" он должен будет послать их нахуй? или сказать форыч греп в одном потоке?

разные устройства или устройства с несколькими физ головками можно конечно на разные потоки сожать, но это уже уровень бога, хоть одна прога такое делает? roflanebalo

я понимаю там сравнение 3-х файлов в kdiff3 там процессор грузится а тут как уже сказали это не критично, но офк лучше оптимизировать чем не оптимизировать, чтобы загрузка процессора стала не .1% а 0.001%.

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

так... а может быть это я долбаёб? Если учитывать где физически расположены фрагменты файлов то может иметь смысл "параллелить" чтобы система их последовательно считывала, кто шарит расскажите так можно или нет, лень гуглить

ааа, ясно, вы просто рофлите

тебе надо просто один поток на чтение файлов, и N на обработку

обычной BlockingQueue хватит для реализации

так... а может быть это я долбаёб? Если учитывать где физически расположены фрагменты файлов то может иметь смысл "параллелить" чтобы система их последовательно считывала, кто шарит расскажите так можно или нет, лень гуглить

 

 

ааа, ясно, вы просто рофлите

Какой же ты дегенерат. Как ты дышать не забываешь с таким iq?

Какой же ты дегенерат. Как ты дышать не забываешь с таким iq?

во сне иногда забываю но это когда сознание уже вырубилось или на гране

Такое чувство, что Zellar и E1azor, это твинки одного и того же человека который к тому же сам с собой общается, неосознанно, а может Hira это еще одна из личностей этого местного Сплита?

ну соре, не сразу понял что тут люди исключительно рофлят: каждый первый пост - бред сумашедшего и это просто ваша такая местная атмосфера, вот уже почти привык, начал понимать

ps

и при этом оказывается пара не бредовых постов(помимо моих) почти на каждой странице(!) - от это настораживало, а теперь понимаю - это просто вишенка на торте, чтобы было красиво

ну соре, не сразу понял что тут люди исключительно рофлят: каждый первый пост - бред сумашедшего и это просто ваша такая местная атмосфера, вот уже почти привык, начал понимать

тебе надо просто один поток на чтение файлов, и N на обработку

обычной BlockingQueue хватит для реализации

эта вся хуйня энкапсулирована в системном уровне (ос, драйвера, платформа)

в случае с джавой лучшее что мы можем сделать (с помощью обычного апи на обычной реализации jvm) - это сказать "вычитай этот файл". для джавы можно блокирующе, можно асинхронно. в конечном счете это будет делать ОС и драйвера только им известным образом, в теории там может быть любое устройство хранения с любым параллелизмом и любой моделью исполнения.

на том уровне на котором мы обсуждали (как это закодить в джава) - это все неважно и зависит от места исполнения (железо, ОС, драйвера ит д) и из джавы в целом не то чтобы доступно управлять этим (только если ты не напишешь свой драйвер и не сделаешь ему биндинги в джава код, или не заиспользуюешь какую-то низкоуровневую магию jvm, которая позволить работать с драйвером напрямую - допускаю что в некоторых кейсах это возможно без запиливания своих драйверов или биндингов)

ты чет белены поел и куда-то не туда полез

я просто про то, что читает файлы один поток, тк жд всё равно тебе не выдаст больше, и читает беспрерывно, как у него получится, а не читает - парсит - читает - парсит

а дальше другие потоки берут прочитанное и ебашут свои фильтры

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