![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
eldhennПринёс из дома две толстых книжки, подложил под монитор. Отобрал у соседа, которого судя по всему на этой неделе нет, кресло чуть пониже чем моё дефолтное, и главное - у него жёсткая спинка!
Всё равно небольшой дискомфорт, но уже гораздо лучше.
Про говнокод. Который необходимо переписать. За каковое желание меня уволили с предыдущей работы. Встретил и здесь тоже, но тут промышленные масштабы. Переписывать пока не стал, как раз потому что промышленные масштабы, мало ли что, боязно пока. Но руки чешутся.
Так вот. Отчёт по банковским транзакциями. За сутки. Сто шестьдесят тысяч записей всего. Общий объём данных (только данных!) - 40Мб. А теперь внимание! Как делается этот отчёт. Выбираем из базы все записи, заносим в локальный массив в памяти. Привет, 160к фетчей. Привет, 40 метров памяти (не считая внутренней, служебной информации из собственно структур данных). Данные разделены на две группы. Логически. Группа А и группа Б. Берём, значица, этот массив (40Мб голых данных), и разбиваем его на два, по признаку разбиения на группы. К счастью, он уже отсортирован, поэтому привет, ещё всего лишь 160 тысяч проходов, и ещё плюс 40Мб данных в памяти (голых, не считая управляющих структур). Потом, значит, из этих двух массивов собираем собственно отчёты, текстовые. Соединяем в два скаляра в памяти. Херак - ещё 160 тыщ проходов, и ЕЩЁ 40Мб памяти. Старые данные никуда не делись! Всё бережно храним! Ну теперь осталась мелочь - записать эти скаляры на диск, в файлы отчётов. Итак, ЕЩЁ РАЗ перебираем 40Мб данных. Ничо, работает. Раз в сутки всего, можно и потерпеть... вот сервер и терпит. Задача для третьего класса школы даунов - подсчитать, сколько раз в памяти встречаются ОДНИ И ТЕ ЖЕ данные, сколько места они вместе занимают, и сколько раз читаются ОДНИ И ТЕ ЖЕ ДАННЫЕ.
А если там не 160 тысяч будет? А десяток миллионов? Ну отчётик не за сутки, а за месяц, скажем?
В Dr.Web конечно таких объёмов не было. Но принципы написанного кода были теми же. Ещё там была хорошая практика выбрать данные из базы в неупорядоченное множество, а потом его уже сортировать. Какая у нас там максимальная эффективность алгоритма сортировки? N*log N? Вот именно.
И такие люди что-то там пеняют мне на скорость и качество работы. Да, я сегодня убил полдня, и в *ленивом* режиме написал механизм сравнения двух таких отчётов. Но каждую запись этот механизм проходит один раз, и в один момент в памяти держит только две записи. Всё.
Печаль.
ДОБАВЛЕНИЕ.
В Dr. Web было даже веселее. Записи из базы выбирались "библиотечной" функцией, выбирались, как я уже сказал, в неупорядоченное множество (точнее в хэш), но самое весёлое было дальше - при возврате из функции всё это КОПИРОВАЛОСЬ. То есть это ещё 160к проходов, плюс одно выделение памяти и одно освобождение памяти для каждого из 160к. Я, блин, без высшего образования, без серьёзного изучения подходов к производительности ПО, понимаю такие вещи.
Всё равно небольшой дискомфорт, но уже гораздо лучше.
Про говнокод. Который необходимо переписать. За каковое желание меня уволили с предыдущей работы. Встретил и здесь тоже, но тут промышленные масштабы. Переписывать пока не стал, как раз потому что промышленные масштабы, мало ли что, боязно пока. Но руки чешутся.
Так вот. Отчёт по банковским транзакциями. За сутки. Сто шестьдесят тысяч записей всего. Общий объём данных (только данных!) - 40Мб. А теперь внимание! Как делается этот отчёт. Выбираем из базы все записи, заносим в локальный массив в памяти. Привет, 160к фетчей. Привет, 40 метров памяти (не считая внутренней, служебной информации из собственно структур данных). Данные разделены на две группы. Логически. Группа А и группа Б. Берём, значица, этот массив (40Мб голых данных), и разбиваем его на два, по признаку разбиения на группы. К счастью, он уже отсортирован, поэтому привет, ещё всего лишь 160 тысяч проходов, и ещё плюс 40Мб данных в памяти (голых, не считая управляющих структур). Потом, значит, из этих двух массивов собираем собственно отчёты, текстовые. Соединяем в два скаляра в памяти. Херак - ещё 160 тыщ проходов, и ЕЩЁ 40Мб памяти. Старые данные никуда не делись! Всё бережно храним! Ну теперь осталась мелочь - записать эти скаляры на диск, в файлы отчётов. Итак, ЕЩЁ РАЗ перебираем 40Мб данных. Ничо, работает. Раз в сутки всего, можно и потерпеть... вот сервер и терпит. Задача для третьего класса школы даунов - подсчитать, сколько раз в памяти встречаются ОДНИ И ТЕ ЖЕ данные, сколько места они вместе занимают, и сколько раз читаются ОДНИ И ТЕ ЖЕ ДАННЫЕ.
А если там не 160 тысяч будет? А десяток миллионов? Ну отчётик не за сутки, а за месяц, скажем?
В Dr.Web конечно таких объёмов не было. Но принципы написанного кода были теми же. Ещё там была хорошая практика выбрать данные из базы в неупорядоченное множество, а потом его уже сортировать. Какая у нас там максимальная эффективность алгоритма сортировки? N*log N? Вот именно.
И такие люди что-то там пеняют мне на скорость и качество работы. Да, я сегодня убил полдня, и в *ленивом* режиме написал механизм сравнения двух таких отчётов. Но каждую запись этот механизм проходит один раз, и в один момент в памяти держит только две записи. Всё.
Печаль.
ДОБАВЛЕНИЕ.
В Dr. Web было даже веселее. Записи из базы выбирались "библиотечной" функцией, выбирались, как я уже сказал, в неупорядоченное множество (точнее в хэш), но самое весёлое было дальше - при возврате из функции всё это КОПИРОВАЛОСЬ. То есть это ещё 160к проходов, плюс одно выделение памяти и одно освобождение памяти для каждого из 160к. Я, блин, без высшего образования, без серьёзного изучения подходов к производительности ПО, понимаю такие вещи.