GaalSpear, странная методика тестирования. Мне кажется - достаточно дорогая в реализации. Можно было как-то больше гипотез вызвинуть об искомом шаблоне. Иначе получим транс-вычислительную задачу.
Вобщем по поиску строк из теории я помню КМП и Боуер-Мур. Ввиду того что у нас нет никаких шаблонов - практически невозможно построить эффективный индекс.
Как можно оптимизировать по скорости? Я думаю в вашем случае - только экстенсивно. Наращивая количество узлов в вашем кластере. Сколько у вас? 12 executors. Вот разделите ваш датасет по хешу на 12 partitions. И пускай каждый исполнитель работает над своим объемом. Не забывайте про fork-join. Освободившиеся исполнители обязаны взять часть работы у других которые еще работают. Потом в конце их результаты надо свести в общий итог.
Что можно поисследовать. Можно построить гистограмму "тригамм". И если какие-то триграммы будут иметь больше количество попаданий - то надо идти за ними в строку и делать соотв. поиск вправо и влево добиваясь макимасльного соотвествия. Учитывая длины строк (по 150Г) возможно я не прав и триграмм будет мало. Берите "квадро-граммы", "квинто-граммы" и так далее до достижения более яркого проявления подстрок-дублей.
Математика может понадобиться чтобы объяснить заказчику почему на данном датасете какая-то гипотеза не сработала.
Также нужно уметь видеть какие-то признаки (выбросы) которые говорят о том что данные - грязные и не годятся для обучения. Строгих критериев тут мало и надо разбираться глубоко в мат-статистике чтобы озвучивать например такие заключения.
Не знаю как реализован в шарпе string.Replace(...) но скорее всего это алгоритм из двух частей.
Первое - это собственно поиск строки. И второе - это генерация новой строки на основе замен старой.
Из алгоритмов поиска я помню 2 штуки. Кнута-Морриса-Пратта и Боуера-Мура. Вот можно в эту сторону
смотреть.
Я думаю что string.Replace(...) реализует вполне себе хороший алгоритм. И если автор хочет делать замены
в гигабайтных строках то стоит наверное глубже изучить предметную область. На что делаем упор? На очень
длинные строки? Будет ли вследствие замен строка сильно увеличена в размере? Какой аллоцировать объем
для билдера? (приблизительо). Будет-ли string.replace работать на регулярной основе.
Может имеет смысл строку индексировать? Но опять-же это можно обсуждать только зная данные.
ErrezMe, тебе скорее всего не нужно учить "OOP in general". Достаточно будет того среза ООП которое использует Python. Вот если Тони Геддис пишет про какие-то термины вроде наследования или композиции в Python - вот их бери и изучай.
Никита Савченко, ну... судя по всему объект cout использует буферизацию. И пока буфер не заполнится - ничего на экран не печатается. Возможно стоило попробовать переводы строк. Но если тут именно важно печатать секунды через многоточия - то тогда команда флаш вроде как форсирует сброс буфера на экран.
Можно посмотреть по ключевому слову VPD (Virtual Private Databases) но в любом случае эта задача требует усилий разработчика больше чем админа или безопасника.
Ну не работает атом. Ну и чорт с ним. Выбросьте его. Возьмите Sublime, VSCode, Notepad++.
Для любого разработчика среды разработки - вторичны. Они могут меняться. Они могут быть или не быть.
Но главное - это собственно текст программы и build-скрипты.
смотри. Во первыйх ты закрываешь не то и не там. А во вторых с точки зрения современной
инфо-безопасности закрытия портов уже недостаточно чтобы считать работу безопасной.
Векторы атаки - более сложные. Например если ты читаешь почту - то уже фактически
можешь быть атакован и ниакакие порты на это не повлияют.
Твое желание закрыть хоть что нибудь или как-нибудь - граничит с бесполезной активностью.
Ты лучше разберись как ты первый раз был заражен. Проведи расследование. Потом создай
условия на учебной машине. Разберись что за пакеты потом от тебя летят. Какое приложение
или процесс это делает. Что внутри этих пакетов. Короче займись анализом причин смерти.
Мэр одного города как-то сказал. Чтобы вода стала горячей - ее надо нагреть.
Вот. Я добавлю - чтобы флешка стала загрузочной - ее на нее надо записать образ нужной ОС.
Вобщем по поиску строк из теории я помню КМП и Боуер-Мур. Ввиду того что у нас нет никаких шаблонов - практически невозможно построить эффективный индекс.
Как можно оптимизировать по скорости? Я думаю в вашем случае - только экстенсивно. Наращивая количество узлов в вашем кластере. Сколько у вас? 12 executors. Вот разделите ваш датасет по хешу на 12 partitions. И пускай каждый исполнитель работает над своим объемом. Не забывайте про fork-join. Освободившиеся исполнители обязаны взять часть работы у других которые еще работают. Потом в конце их результаты надо свести в общий итог.
Что можно поисследовать. Можно построить гистограмму "тригамм". И если какие-то триграммы будут иметь больше количество попаданий - то надо идти за ними в строку и делать соотв. поиск вправо и влево добиваясь макимасльного соотвествия. Учитывая длины строк (по 150Г) возможно я не прав и триграмм будет мало. Берите "квадро-граммы", "квинто-граммы" и так далее до достижения более яркого проявления подстрок-дублей.