Не могу не похвастаться

[catpad]

Только что мне удалось улучшить быстродействие нашей главной программы почти в 250 раз. Я, честно говоря, думал, что получится убыстрить в 2-3 раза, но не в 250 же! Файл, который обрабатывался за 12 минут, теперь обрабатывается за 3 секунды. Проблемы всех прошлых недель, из-за которых тут ночевало 50 человек, теперь решены.
Достижение тут, конечно, не в смысле чего-то очень уж хитроумного - всего-то я потратил 3 часа на программирование и 0 на отладку (как-то оно само собой заработало) - но в смысле значимости этого дела.
Такая штука, однако, может сильно повлиять на один сильно запутанный бизнес-вопрос. HP, на сервере которого работает наша программа, хочет за очень большие деньги продать J-Phone новый сервер GS160 с 16 CPU. Они ссылаются на то, что программа не в состоянии обрабатывать увеличивающееся количество информации на старом сервере. И она, действительно, была не в состоянии.
А что же они скажут теперь, получив 250-кратное убыстрение ? Подгадил я им знатно, ничего не скажешь.

Comments

то есть на самом деле, черная магия есть

[alexcohn.livejournal.com]

Из Вашего объяснения следует, что черной магией следует считать -

а) частые SQL запросы, вместо того чтобы получить всю информацию за один раз, и потом обрабатывать

б) поиск "в лоб" внутри структурированного буфера

разоблачаем заведомо ложные представления о том

а) что уж Oracle-то сможет сделать эффекитивный кэш запросов

б) что сажатьстроить дерево дольше, чем выполнить несколько раз strstr() или какой нибудь InStr()..

Re: то есть на самом деле, черная магия есть

[catpad.livejournal.com]

а) частые SQL запросы, вместо того чтобы получить всю информацию за один раз, и потом обрабатывать

По-моему, это очевидно. Oracle делает кучу всякой фигни, кроме простого ответа на вопросы - пошет в redo log, archive и чёрт знает, что ещё. Кроме того, механизмы связи с ним не очень (мне во всяком случае) понятны, но, насколько можно судить, там замешаны сокеты даже внутри одной машины (в файле tnsnames.ora определяется host и port, а ещё запускается некий listener. Тут я не специалист, однако).
Учтём ещё и следующую вещь: множество программ обращаются к тому же самому Oracle instance параллельно. Отсюда - зависание запросов (wait event), диск IO и так далее. Сервер у нас не параллельный.

б) поиск "в лоб" внутри структурированного буфера
разоблачаем заведомо ложные представления о том
а) что уж Oracle-то сможет сделать эффекитивный кэш запросов

Oracle, конечно, может сделать эффективный кэш (который shared pool), но - см. выше.

б) что сажатьстроить дерево дольше, чем выполнить несколько раз strstr() или какой нибудь InStr()..
Это я не понял. Дерево сажать дольше, но искать-то по нему не в пример быстрее. Кроме того, задача поиска тут довольно хитро поставлена. Я просто придумал для неё идеальную структуру данных - именно для такого поиска (не уверен, кстати, что она и в самом деле B-tree, просто, кажется, похожа на него. Я не помню, как это дерево в точности определяется, я эту структуру сам придумал).

спора не получится

[alexcohn.livejournal.com]

потому что говорим мы одно и то же, ты просто не заметил фразы "заведомо ложные представления"...

Когда мне говорят: "нужно выполнить поиск один раз", я пишу процедуру поиска; если говорят "нужно выполнить немножко поисков", я пишу парсер буфера. Потому что "немножко" меньше 1024 не бывает.