Для того, чтобы понимать, дают ли мои изменения положительный эффект на быстродействие программы я решил использовать такую метрику: Rspec тест проверяющий затрачиваемую память
Программа поставлялась с тестом. Выполнение этого теста в фидбек-лупе позволяет не допустить изменения логики программы при оптимизации.
Для того, чтобы иметь возможность быстро проверять гипотезы я выстроил эффективный feedback-loop, который позволил мне получать обратную связь по эффективности сделанных изменений за время, которое у вас получилось
Вот как я построил feedback_loop: По примеру работы с первой задачей сделал выборки из data_large на
Для того, чтобы найти "точки роста" для оптимизации я воспользовался инструментами, которыми вы воспользовались
Вот какие проблемы удалось найти и решить
- какой отчёт показал главную точку роста
- как вы решили её оптимизировать
- как изменилась метрика
- как изменился отчёт профилировщика
- какой отчёт показал главную точку роста
- как вы решили её оптимизировать
- как изменилась метрика
- как изменился отчёт профилировщика
- какой отчёт показал главную точку роста
- как вы решили её оптимизировать
- как изменилась метрика
- как изменился отчёт профилировщика
В результате проделанной оптимизации наконец удалось обработать файл с данными. Удалось улучшить метрику системы с того, что у вас было в начале, до того, что получилось в конце и уложиться в заданный бюджет.
Какими ещё результами можете поделиться
Для защиты от потери достигнутого прогресса при дальнейших изменениях программы о performance-тестах, которые вы написали
При первом прогоне профайлера выявлено значительное потребление памяти на сложении массивов(более 70 процентов потребления). sessions = sessions + [parse_session(line)] if cols[0] == 'session' В комментариях к выполнению задачи было указание на переписывание программы на потоковый стиль. Начнем сразу т.к в файлах данных строгая последовательность пользователь-сессия-сессия, то можно заинициализировать класс и добавлять в него данные по мере наполнения, а после полного сбора привести их к требуемому формату
Таким образом мы обработаем второй тяжелый поинт из отчета не пробегая по массиву пользователей раз за разом user_sessions = sessions.select { |session| session['user_id'] == user['id'] }
При очередном прогоне теста было замечено высокое потребление на моменте перебора строк файла через each. Написав небольшой бенчмарк для сравнения скорости работы методов чтения из файла был получен метод foreach который в 8 раз быстрее обрабатывает файл построчно.
Сначала я пытался добавлять пользователей в массив, дообогащать его рассчетами и записывать в файл преобразованное в json, но при прогоне теста было большое потребление на обработку файловых операций. Немного костыльными методами было решено разбить структуру предполагаемого файла на отдельные элементы, включая технические "{}, ", ," и дописывать в файл по мере необходимости.
В результате проделанной оптимизации удалось обработать файл с данными 1кк c целевыми показателями по использованной памяти. Причем показатели потребления не меняются при увеличении обьема данных.
При первой итерации пробовал пойти через перенос структуры данных в отдельные файлы. И гипотеза успешно отработала на файле до 1кк записей, но при увеличении объема затраты на запись и чтение свели весь прогресс на нет.