Не могу не похвастаться
Aug. 7th, 2003 01:44 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
catpad
Только что мне удалось улучшить быстродействие нашей главной программы почти в 250 раз. Я, честно говоря, думал, что получится убыстрить в 2-3 раза, но не в 250 же! Файл, который обрабатывался за 12 минут, теперь обрабатывается за 3 секунды. Проблемы всех прошлых недель, из-за которых тут ночевало 50 человек, теперь решены.
Достижение тут, конечно, не в смысле чего-то очень уж хитроумного - всего-то я потратил 3 часа на программирование и 0 на отладку (как-то оно само собой заработало) - но в смысле значимости этого дела.
Такая штука, однако, может сильно повлиять на один сильно запутанный бизнес-вопрос. HP, на сервере которого работает наша программа, хочет за очень большие деньги продать J-Phone новый сервер GS160 с 16 CPU. Они ссылаются на то, что программа не в состоянии обрабатывать увеличивающееся количество информации на старом сервере. И она, действительно, была не в состоянии.
А что же они скажут теперь, получив 250-кратное убыстрение ? Подгадил я им знатно, ничего не скажешь.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
ого...
Date: 2003-08-06 10:08 pm (UTC)а поподробнее о программе можно?...
Re: ого...
Date: 2003-08-06 10:22 pm (UTC)Re: ого...
Date: 2003-08-06 11:40 pm (UTC)быстрее ^__^
no subject
Date: 2003-08-06 10:37 pm (UTC)no subject
Date: 2003-08-06 10:58 pm (UTC)no subject
Date: 2003-08-06 11:49 pm (UTC)no subject
Date: 2003-08-06 11:56 pm (UTC)Однако, давно известно, что
Date: 2003-08-07 01:16 am (UTC)Чего Вы посоветуете избегать тем из нас, у кого нет лишних денег на GS160? Может, там пользовались какой-то принятой в биллинге технологией, которая специально так жутко тормозит?
Re: Однако, давно известно, что
Date: 2003-08-07 01:28 am (UTC)Два фактора повлияли на торможение:
1) таблица не была загружена в память, а обращение всё время происходило к Ораклу;
2) поиск по таблице был просто дубовый - квадратный, то есть. Я посадил её в память и организовал в виде B-tree.
Всё просто, а существовавшее положение можно объяснить только полной бездарностью разработчиков.
то есть на самом деле, черная магия есть
Date: 2003-08-07 01:51 am (UTC)а) частые SQL запросы, вместо того чтобы получить всю информацию за один раз, и потом обрабатывать
б) поиск "в лоб" внутри структурированного буфера
разоблачаем заведомо ложные представления о том
а) что уж Oracle-то сможет сделать эффекитивный кэш запросов
б) что
сажатьстроить дерево дольше, чем выполнить несколько раз strstr() или какой нибудь InStr()..Re: то есть на самом деле, черная магия есть
Date: 2003-08-07 02:08 am (UTC)По-моему, это очевидно. Oracle делает кучу всякой фигни, кроме простого ответа на вопросы - пошет в redo log, archive и чёрт знает, что ещё. Кроме того, механизмы связи с ним не очень (мне во всяком случае) понятны, но, насколько можно судить, там замешаны сокеты даже внутри одной машины (в файле tnsnames.ora определяется host и port, а ещё запускается некий listener. Тут я не специалист, однако).
Учтём ещё и следующую вещь: множество программ обращаются к тому же самому Oracle instance параллельно. Отсюда - зависание запросов (wait event), диск IO и так далее. Сервер у нас не параллельный.
б) поиск "в лоб" внутри структурированного буфера
разоблачаем заведомо ложные представления о том
а) что уж Oracle-то сможет сделать эффекитивный кэш запросов
Oracle, конечно, может сделать эффективный кэш (который shared pool), но - см. выше.
б) что сажатьстроить дерево дольше, чем выполнить несколько раз strstr() или какой нибудь InStr()..
Это я не понял. Дерево сажать дольше, но искать-то по нему не в пример быстрее. Кроме того, задача поиска тут довольно хитро поставлена. Я просто придумал для неё идеальную структуру данных - именно для такого поиска (не уверен, кстати, что она и в самом деле B-tree, просто, кажется, похожа на него. Я не помню, как это дерево в точности определяется, я эту структуру сам придумал).
спора не получится
Date: 2003-08-07 02:21 am (UTC)Когда мне говорят: "нужно выполнить поиск один раз", я пишу процедуру поиска; если говорят "нужно выполнить немножко поисков", я пишу парсер буфера. Потому что "немножко" меньше 1024 не бывает.
no subject
Date: 2003-08-07 07:51 am (UTC)Тем более, что я потратил на переписывание три дня.
Спасает меня лишь то, что никаких обращений к БД в процессе не было -
пришлось заново писать бизнес-логику.
Автор изначального кода лидирует в списке персон,
которым нужно оторвать яйца, опережая всю Ось Зла.
Я как то о нем писал, с примерами программ.
Помнишь, тот, который обращался к методу суперкласса через this. ?
no subject
Date: 2003-08-07 06:12 pm (UTC)Однако на Оси Зла тут в известной нам фирме такие писатели сидят, что твой автор, я думаю, просто жалкий эпигон.
no subject
Date: 2003-08-07 04:42 pm (UTC)no subject
Date: 2003-08-12 07:23 am (UTC)Может, тебе договор продлят!?
no subject
Date: 2003-08-12 05:11 pm (UTC)Впрочем, это здесь совершенно стандартная практика, и меня ничуть не удивляет.
маленький вопрос
Date: 2003-08-18 12:30 am (UTC)поддерживающаяся из Израиля (или мне так показалось?) - ето не продукт Амдокса случайно?
Re: маленький вопрос
Date: 2003-08-18 12:35 am (UTC)