Свое сообщение выше переписал, файл "log.txt" сократил до 5000 строк
Для чего тебе такие большие файлы логов? Все скрипты, работающие более нескольких секунд, обычно построены на цикличности (не беря во внимание особые случаи). Если будет какая-то ошибка, из-за которой скрипт что-то не сделает, то эта ошибка повторится в цикличности и ища ее в логах, ты найдешь ее повторяющейся в ста, ну пусть - в двести-триста, строчках. Зачем 5 тысяч-то...?
Сейчас за этим вопросом последует 5 тысяч+ букв в ответ.
Дело в том, что эти самые "логи" не есть логи работы Кликермана, в которых надо отловить ошибку, а логи из игры. Например логи крафта игровых предметов. Предполагается, что эти логи могут быть очень большими и содержать множество уникальных названий предметов на кирилице. Одна строка - один предмет + рандомный "мусор" в виде различных печатных символов и пробелов, хаотично разбросанных по строкам, но не внутри названий предметов. Это как я понял задачу.
Уникальных предметов много и в логе их названия могут повторяться в разных строках. Задача в том, чтобы посчитать сколько раз каждый предмет был записан в лог.
Такой лог и есть входные данные для скрипта, его нельзя крутить в цикле, а нужно обработать всего один раз и вывести результат.
Настоящий игровой лог я не видел, потому сделал его сам, напихав в строки "мусора" в виде - "-=+!№;%:?*()@#$^&{},0". А размер этих логов в несколько тысяч строк, как раз для того, что бы выявить преимущества/слабости разных алгоритмов. На малых объемах данных различия в работе, даже сильно отличающихся сценариев, почти не видны, нет наглядности. Кстати 5к строк это не много, но результаты тестов уже впечатляют (я приведу примеры).
Теперь про алгоритмы и тесты. Всё стало совсем интересно когда отписался сам Johnny, сообщив - "у нас нет ассоциативных массивов" (расцениваю как подсказку) и расписал альтернативный алгоритм, с припиской "ну это тем разумеется адресовано, кто захочет размять мозги". Мне мозги долго разминать не пришлось, они у меня итак мягкие "как титька",
ведь моей первой темой на этом форуме была как раз затронута тема про эти самые ассоциативные массивы, но не в обычном их виде, а в образе ini-файлов.
Было это здесь (см. "Второй вариант"). Atas тогда сказал - "Johnny давно всё смог и придумал, нам осталось только правильно этим воспользоваться". Меня тогда порадовал нестандартный подход Атаса к проблеме и удивила скорость работы INIWRITE(), хотя это работа с жестким диском. Как видно из той темы, такой подход тогда был революционным и сегодня похоже стал незаслуженно забытым. Спасибо Atas еще раз.
Первым "установил планку" Андрей, реализовав алгоритм предложенный Johnny. Алгоритм, который есть ничто иное как всем известный брутфорс. Скорость работы которого зиждется на малом количестве данных, которые он перебирает. И в примере с пятью искомыми предметами в логе он легко справлялся.
Я провел тесты для всех предложенных в этой теме алгоритмов, на одних и тех же данных (лог в 5000 коротких строк и 203 уникальных предмета).
Скрипт Андрея показал время 155482 ms. Окно вывода (dialogbox) на моем мониторе не уместилось.
Qwerry изначально имела свою идею и пошла своим путем, она "подняла планку" сразу в 2,6 раза. Её скрипт разобрал тот же лог за 59502 ms. Алгоритм - тоже полный перебор и сравнение.
Скромно скомунизденный мной Atas-ный алгоритм "схавал" те же данные за 3992 ms, что в 14,9 раз быстрее скрипта Qwerry и в 38,9 раз быстрее скрипта Андрея. В алгоритме никакого перебора и никаких сравнений нет, просто кинул в в ini-файл и всё.
Ну и сортировку я от себя добавил, это улучшает читаемость результатов.
Причем при разборе механики INIWRITE(), вскрылась незадокументированная способность этой функции обрезать пробелы слева и справа от имени параметра. Опять же большой плюс к быстродействию. Запишу как открытие на свой счет, если никто не предъявит претензий. Я пробовал отрезать эти пробелы двумя циклами, и это увеличивало время работы скрипта почти на 50%.
Так что, можно сказать, ассоциативные массивы у нас есть и они неплохо работают.
Если кому интересно - во вложении архив со скриптами для тестов.
