Comments 18
2. Код выглядит правильным
вернее, он правильный с точки зрения результата. Но опытному взгляду, подобная реализация сразу бросается в глаза.
Скрипт работал почти 9 минут,
А времени на все оптимизации потратили гораздо больше.
Да, но если у тебя этот скрипт запускается периодически в каком нибудь celery и его выполнения ждут остальные задачи...
Если.
Даже в таких случаях, зачастую это бывает некритично чтобы лезть заморачиваться. А то и вовсе необходимость в самом скрипте отпадает через пару дней.
Перфекционизм обыкновенный, МКБ-11 MB28.C
А потом удивляемся откуда столько говнокода
Скрытый текст
"Premature optimization is the root of all evil" is a famous maxim by Donald Knuth (1960s), advising developers to focus on clarity and correctness over micro-optimizations. It argues that spending time on performance improvements before identifying true bottlenecks wastes resources, increases complexity, and yields harder-to-maintain code.
Что менее важно, такая оптимизация делается быстрее 9 минут. Важнее - научиться видеть подобные пессимизации на пустом месте. Так что автор молодец - это окупится десятки раз
Оптимизацию делал ИИ, он же и пост писал. Да?
Отличный вопрос! Давайте разберём всё по порядку. Во-первых, ...
:)
"Придумай неоптимальный код на Python, который медленно работает, и который можно легко ускорить за счёт оптимизации. Напиши статью по этой теме для Хабра"
Это делал человек с помощью ИИ, что ещё забавнее т.к. улучшать код ещё есть куда, но этого не сделано. Можно же было просто закинуть статью в ллм и попросить улучшить, проверить на ошибки, etc.
from collections import defaultdict
def count_actions(file_path):
users = defaultdict(int)
with open(file_path) as f:
for line in f:
user_id = line.split()[1]
users[user_id] += 1
return users
А если уникальных юзеров будут миллионы, то словарь users может занять много памяти.
А если строка не соответствует паттерну и user_id не будет нужным id, вместо id будет текст ошибки или пробелы или второго элемента вообще не будет, или это пустая строка? Ещё может быть проблема с кодировкой при чтении файла. И ещё если бы user_id был числом, то должно быть быстрее и словарь users будет занимать меньше места, т.е. нужно перед users[user_id] += 1 переводить user_id в int.
Изначальная реализация не только медленная, но ещё и менее читабельна. Выглядит как написанная студентом ещё не освоившим словари.
А если загрузить в pandas dataframe, быстрее не будет?
Квадратичная сложность прямо бросается в глаза тем, кто хоть чуть-чуть щупал алгоритмы и структуры данных. И до профайлинга не дошло бы. Использовать Counter было бы ещё проще.
Как я ускорил Python-скрипт в 42 раза, убрав один незаметный цикл