Microsoft таки must die
Давным-давно, когда операционные системы фирмы Микрософт еще не поддерживали вытесняющую многозадачность, среди программистов было принято ругать продукты этой фирмы. Операционки ругали за дело, а остальные программы - за компанию. С тех прошло много времени, компания Микрософт наладила контроль качества, и ругать ее стали значительно меньше (IT-шники, по крайней мере). Однако, сегодня таки я обнаружил грандиозный повод для ругани.
Итак, ситуация: имеется база данных, развернутая на DB2 9, содержащая многие десятки тысяч записей в определенной таблице. Имеется софтинка, написанная на C++ и скомпилированная при помощи Visual Studio 2005. Софтинка с некоторой периодичностью должна коннектиться к той самой базе и обрабатывать данные из той самой единственной таблицы. В текущей реализации софтинка работает, что называется, "в лоб". Тупо грузит весь набор записей из таблицы в память, и уже потом сиплюсплюсный код решает, какие из этих записей нужно дальше обрабатывать. А специфика заполнения таблицы данными такова, что хорошо если 1% записей пригодны для обработки. Остальные 99% тупо жрут память и машинное время. И если гиг-другой лишней отожранной памяти в наше время - пустяки, то производительность лишней не бывает.
Встал вопрос оптимизации софтинки. Казалось бы, есть очевидное решение: модифицировать SQL-запрос, возвращающий исходные данные, таким образом, чтобы возвращались только те записи, которые заведомо подходят для дальнейшей обработки. Разумеется, за счет усложнения SQL-запроса время выборки исходных данных непременно увеличится, но за счет того, что обрабатывать придется в 100 раз меньший набор данных, я надеялся получить выигрыш в быстродействии.
Итак, коллеги-программисты помогли написать навороченный SQL-запрос, который бы отсеивал всякую ненужную шелупонь и выдавал бы только нужные данные в красивом виде. Погонял запрос в Quest Central на тестовой базе, прикинул, насколько увеличивается время выборки с ростом числа записей во всей таблице. Получилось, что для тысячи записей время выборки по сравнению со старым запросом увеличилось на 2 секунды, для двух тысяч записей - на 2.1, для трех тысяч - на 2,2, для 10 тысяч - на
три секунды. Ну, думаю, классно, вполне пологий график падения производительности рисуется, меня устраивает, сейчас только в сишный код свой запрос заверну - и все классно и шустро заработает. Ага, как бы не так!
Результат работы "оптимизированного" запроса, прописанного в SQX-файл и скомпилированного Microsoft Visual Studio 2005, поверг меня в шок. На том же наборе данных рост времени выборки составил: для тысячи записей - семь секунд, для двух тысяч - 21 секунда, для трех тысяч - 87 секунд, а для 10 тысяч счет пошел на десятки минут, и завершения работы я так и не дождался. График снижения производительности рисовал дурную экспоненту вместо ожидаемого плавного пологого спуска!
Пошел за разъяснениями к нашему ведущему программисту. Оказалось, что вот так вот компилирует и выполняет запросы стандартная библиотека, входящая в состав Visual Studio. Сделать ничего нельзя. Так что, пришлось мне довольствоваться половинчатым решением - оптимизировать запрос так, чтобы он возвращал не 99% мусора, а только 50%. И оставшийся мусор уже в сишном коде отфильтровывать. А нанятые Микрософтом индусы, создавшие такую библиотеку для типа работы с типа промышленными объемами данных, надеюсь, обратно в свою Индию поедут и вернутся к профессии погонщиков слонов.
Итак, ситуация: имеется база данных, развернутая на DB2 9, содержащая многие десятки тысяч записей в определенной таблице. Имеется софтинка, написанная на C++ и скомпилированная при помощи Visual Studio 2005. Софтинка с некоторой периодичностью должна коннектиться к той самой базе и обрабатывать данные из той самой единственной таблицы. В текущей реализации софтинка работает, что называется, "в лоб". Тупо грузит весь набор записей из таблицы в память, и уже потом сиплюсплюсный код решает, какие из этих записей нужно дальше обрабатывать. А специфика заполнения таблицы данными такова, что хорошо если 1% записей пригодны для обработки. Остальные 99% тупо жрут память и машинное время. И если гиг-другой лишней отожранной памяти в наше время - пустяки, то производительность лишней не бывает.
Встал вопрос оптимизации софтинки. Казалось бы, есть очевидное решение: модифицировать SQL-запрос, возвращающий исходные данные, таким образом, чтобы возвращались только те записи, которые заведомо подходят для дальнейшей обработки. Разумеется, за счет усложнения SQL-запроса время выборки исходных данных непременно увеличится, но за счет того, что обрабатывать придется в 100 раз меньший набор данных, я надеялся получить выигрыш в быстродействии.
Итак, коллеги-программисты помогли написать навороченный SQL-запрос, который бы отсеивал всякую ненужную шелупонь и выдавал бы только нужные данные в красивом виде. Погонял запрос в Quest Central на тестовой базе, прикинул, насколько увеличивается время выборки с ростом числа записей во всей таблице. Получилось, что для тысячи записей время выборки по сравнению со старым запросом увеличилось на 2 секунды, для двух тысяч записей - на 2.1, для трех тысяч - на 2,2, для 10 тысяч - на
три секунды. Ну, думаю, классно, вполне пологий график падения производительности рисуется, меня устраивает, сейчас только в сишный код свой запрос заверну - и все классно и шустро заработает. Ага, как бы не так!
Результат работы "оптимизированного" запроса, прописанного в SQX-файл и скомпилированного Microsoft Visual Studio 2005, поверг меня в шок. На том же наборе данных рост времени выборки составил: для тысячи записей - семь секунд, для двух тысяч - 21 секунда, для трех тысяч - 87 секунд, а для 10 тысяч счет пошел на десятки минут, и завершения работы я так и не дождался. График снижения производительности рисовал дурную экспоненту вместо ожидаемого плавного пологого спуска!
Пошел за разъяснениями к нашему ведущему программисту. Оказалось, что вот так вот компилирует и выполняет запросы стандартная библиотека, входящая в состав Visual Studio. Сделать ничего нельзя. Так что, пришлось мне довольствоваться половинчатым решением - оптимизировать запрос так, чтобы он возвращал не 99% мусора, а только 50%. И оставшийся мусор уже в сишном коде отфильтровывать. А нанятые Микрософтом индусы, создавшие такую библиотеку для типа работы с типа промышленными объемами данных, надеюсь, обратно в свою Индию поедут и вернутся к профессии погонщиков слонов.