Ускорение SMO v.10: дело не в запросах

Мне все никак не дает покоя причина увеличение скорости работы SMO v.10 (см. здесь). Все думал: ну ничего себе, насколько, оказывается, можно эффективно (или неэффективно) работать с метаданными! Возникло сильное желание узнать: как нужно и как не нужно делать.

Разбор полетов начал с профайлера (слева - версия 10, справа - 9):

Говоря по-простому: на уровне запросов к базе не поменялось ничего. По содержанию. А вот форма немного изменилась. Если в версии 9 все запросы генерировались динамически (т.е. для каждого объекта создавался свой запрос), то в версии 10 используются запросы с явной параметризацией, что по-идее существенно облегчает работу сервера - не надо на каждый запрос создавать новый план выполнения. Мониторинг сервера во время создания скриптов базы с помощью dbbuilder показывает, следующее:

• для SMO v.9 практически на каждый запрос создается новый план выполнения (даже для однотипных запросов), повторного использования планов не происходит;
• для SMO v.10 план типовых запросов в большинстве случаев используется повторно.

В целом ожидаемо. Но дальше начинается интересное. Если проанализировать статистику выполнения этих запросов (суммарное время выполнения, общая нагрузка на подсистемы ввода/вывода и загрузка процессора), то обнаруживается, что разница между версиями во-первых не так уж и велика, а во-вторых, по "чистому времени выполения запросов" она даже не в пользу новой версии (v9: 19.5 s, v.10: 26 s).

Так что версию о том, что причина ускорения кроется в эффективности/неэффективности самих запросов (или способа их выполнения) скорее всего нужно отбросить.

Начал было "ковыряться" в коде SMO, но что-то пока без особого успеха (слишком уж его много).

Чисто для себя решил выяснить разницу по производительности (измеренную на уровне приложения) между параметризированными запросами и динамически сгенерированным SQL. Для простых запросов эта разница составляет около 20%, что тоже неплохо.

svn:keywords и Unicode

Давно хотел, чтобы все было как у людей: в каждом файле в заголовке - номер последней ревезии, в которой этот файл изменялся, автор изменений и дата. Такой заголовок особенно полезен для sql - скриптов, которые создают хранимые процедуры и пользовательские функции (в общем: логику), ибо позволяет заглянув в базу сразу же узнать кто и когда менял тот или иной объект.

Для тех, кому повезло использовать SVN для контроля за версиями (мне, как раз повезло), есть, казалось бы, простой и безболезненный способ - svn:keywords. Выставляем для sql (или любого другого) файла это свойство (см. руководство по TortoiseSVN здесь), и в файле используем ключевые слова, например так:

-- $Rev$

-- $Author$

CREATE PROCEDURE ...

и вот оно счастье...

Но не тут-то было! Проблема появляется оттуда, откуда ее никто не ждал. SQL Server Management Studio по-умолчанию сохраняет все файлы в формате Unicode. Причем не просто Unicode, а UTF-16 с byte-order mark. Точно также поступают и некоторые библиотеки (в частности SMO). А SVN помечает файлы в этой кодировке как имеющие mime-type: octet-stream/application - т.е. фактически считает их бинарными и, соответственно, никакой подстановки ключевых слов не делает. Обидно, тем более, что файл-то текстовый.

Поиск в Google дает мало толковых результатов: да, есть такая проблема, можно попытаться обойти (и то, сайт недоступен, можно почитать только из кэша Google). И только покопавшись еще глубже, можно обнаружить вот это: SVN поддерживает Unicode, но текстовым будет считаться только файл в кодировке UTF-8 (а не UTF-16 или UTF-32) - соответсвенно и ключевые слова будут работать только если файл в одной из однобайтовых кодировок (верх "крутизны" - та самая UTF-8).

Ну лучше уж так, чем никак. В результате:

• быстренько сделал утилиту по переконвертированию файлов в кодировку UTF-8 (зачем пользоваться shareware, если самом сделать - дело 5ти минут? ;) ). Исполняемый файл здесь, исходник (если кому интересно) здесь.
• сделал так, что dbbuilder теперь сохраняет все скрипты в кодировке UTF-8

Надеюсь кому-нибудь поможет.

AlexS