Formobject.Hide

• Избегая загрузки запросов, загрузки форм и этапов визуализации элементов управления, можно значительно повысить производительность интерфейса. Недостатки такого подхода заключаются в том, что скрытые формы требовательны к памяти и это может отрицательным образом сказаться на других модулях приложения. Хотя данную методику нельзя использовать для всех форм в приложении, ее рекомендуется применять для часто используемых форм.

Работая с очень большими наборами записей, не следует пытаться представить пользователю все за­писи за один раз. В любом случае большинство пользователей не знает, что делать с десятками тысяч записей, отображенными одновременно. Но если пользователи работают с многопользовательским прило­жением и форма открывает набор записей из больших таблиц или запросов, производительность падает по причине заторов в сети, ограничений кэша, блокировок записей и страниц и других перегрузок. Лучше всего отыскать логический способ, позволяющий разбить данные на логические подмножества с опреде­ленными ограничениями. Еще лучше отображать для пользователя только одну запись в определенный момент времени, запрашивая начальное значение записи или индекс поля. В небольших приложениях такой подход может привести к снижению производительности, но в больших многопользовательских системах это единственный выход. Для реализации такого решения необходимо переписать SQL-опсратор в коде, программно меняя свойство формы Record Source и многократно запрашивая форму.

Повышение скорости печати отчетов

Какой смысл в быстродействующей базе данных, если она целый день распечатывает отчет? Единственная большая и оказывающая влияние на производительность разница между формами и отчетами заключается в способе обработки разделов. В форме существует заголовок формы, область дан­ных и примечание формы. В отчете имеются заголовок и примечание отчета, заголовок и примечание страницы, заголовки и примечания разделов, а также область данных. При открытии формы запрос, на котором она основана, выполняется только один раз. При открытии отчета он должен создать запрос (основываясь на запросе в источнике записей) для каждого раздела. Если запрос очень сложен, отчет должен выполнять его или ^некоторые его части несколько раз.

Ниже приводятся советы, следуя которым можно повысить скорость создания отчетов.

• Запрос, на котором основывается отчет, должен быть как можно более простым.

• Рекомендуется перенести вычисления в отчет. Если поместить вычисления в запрос, они будут вы­полняться для каждой строки. Однако, если поместить вычисления в отчет, они будут выполнять­ся только при необходимости и пользователь сразу после расчета одной страницы данных Access увидит результат.

• Следует основывать запрос на возможно меньшем количестве таблиц. Поскольку отчет выполняет запрос больше чем один раз, может оказаться полезным создать таблицу необходимого результи­рующего набора. Отчет может обработать эту таблицу гораздо быстрее, чем снова выполнить зап­рос. Данный подход особенно полезен в том случае, если отчет основан на запросах с подчиненными запросами.

• Необходимо избегать использования подчиненных запросов в источнике отчета. Отчетам необходим большой объем памяти, а запрос с подчиненными запросами поглощает больше памяти, чем тре­буется в действительности.

• Следует проверить, необходим ли на самом деле подчиненный отчет. Подчиненные отчеты не только усложняют форматирование вывода, но и поглощают память, а также снижают производительность отчета. Тем не менее, подчиненные отчеты имеют широкое применение. Если существует несколь­ко доменных функций, может оказаться,что подчиненный отчет выполняется быстрее, чем несколь­ко вызовов данных функций.

• Необходимо избегать сортировки или группировки выражений. Чтобы правильно отображать сорти­ровку или группировку. Access будет вынужден просчитывать каждое выражение больше чем один раз. Значения следует рассчитать до того, как они перейдут в отчет.

• Рекомендуется индексировать все поля, использующиеся для сортировки или группировки. Поскольку индексы по умолчанию сортируют записи, отчет без особых сложностейможет отсортировать и сгруппировать данные непосредственно из индексированных полей.

• Источник записей не должен содержать агрегирующие доменные функции (DIookup). Снова это вынуждает отчет выполнять дополнительную обработку данных, что задерживает отображение от­чета.

• Нет смысла в отображении для пользователей пустого отчета с записями#Еггог. Если отчет не содержит данных, следует отправить пользователю соответствующее сообщение и закрыть отчет. Оп­ределить, содержит ли отчет данные для отображения, можно с помощью свойствHasData или NoData.

Многие из методик, которые используются для повышения производительности форм, можно исполь­зовать и для отчетов. В данном разделе были описаны только те подходы, которые ограничиваются отче­тами.

Создание высокопроизводительного кода

Что касается кода, существует несколько способов, обеспечивающих более быстрое выполнение фун­кций и подпрограмм. Хотя разница в скорости между одной методикой и другой заключается лишь в долях секунды, использование самой быстрой методики может предоставить больше возможностей для после­дующего повышения производительности. Когда к разработчику обращаются пользователи с просьбой о модификации, всегда лучше иметь некоторый резервный запас функциональных свойств, которым мож­но воспользоваться для вставки аудиторских следов и сложных контрольных процедур, чтобы не испы­тывать терпение пользователей.

Разработчик обнаружит, что внедрение некоторых методик, описанных выше в данной статье, позво­ляет упростить оптимизацию кода. Самая большая помеха для кода — это плохо разработанная база дан­ных. Если база данных разработана плохо, почти каждая функция и подпрограмма будет содержать ошибки и использовать обходные пути. Применение искусственных приемов всегда замедляет выполнение програм­мы по сравнению со стандартной методикой.

Однако существует несколько простых правил, которых необходимо придерживаться, и несколько альтернативных методик, используя которые можно добиться максимальной скорости выполнения фун­кций и подпрограмм приложения. Очень не многие из описанных подходов сами по себе оказывают более или менее значительный эффект, но их совместное и многократное применение приводит к поразитель­ным результатам.

Использование памяти кодом

Access вызывает в память модули, все подпрограммы и функции, в них содержащиеся, используя метод загрузки дерева вызовов. Это означает, что, если функция А первого модуля вызывает функцию В пер­вого модуля, а последняя, в свою очередь, — функцию С второго модуля, Access загружает в память целиком первый модуль и весь второй модуль. В памяти остаются оба модуля. Таким образом, имеет смысл

группировать модули в логические блоки. Если функции и модули часто вызывают друг друга, их следует записать в один модуль для уменьшения непроизводительных издержек и количества загрузок модулей. Необходимо также удалить все функции и процедуры, не используемые приложением.

VBA, кроме того, загружает модуль, если существует ссылка на глобальные переменные данного модуля. Разработчику следует убедиться, что глобальные переменные разумно сгруппированы в модулях.

Работа с модулями

Перед выполнением модулейVBA должен скомпилировать их. Это не значит, что модули не будут работать, если их специально не скомпилировать, просто перед выполнением модуля VBA будет вынуж­ден временно скомпилировать его. Кроме того, модуль будет компилироваться каждыйраз, когда егонеобходимо выполнить. Это может сильно сказаться на производительности.

При компиляции модуля VBA преобразовывает его в гораздо более меньший по размеру, быстрее выполняющийся блок. Хотя исходный код всегда хранится в файле .MDB, Access загружает и выполняет только скомпилированный код VBA. Код VBA, кроме того, не содержит пробелов, комментариев, заго­ловков и занимает гораздо меньший объем памяти, чем созданный разработчиком исходный код. При попытке выполнить нескомпилированную процедуру VBA должен загрузить весь исходный код (с пробе­лами, комментариями и невыполняемым кодом) в память и скомпилировать перед выполнением. То же самое происходит при выполнении кода форм и отчетов.

Компиляция кода

Можно скомпилировать код, выбрав в меню пункты Debug j Compile projectname (Отладка | Скомпили­ровать имя_проекта). Перед распространением приложения необходимо обязательно скомпилировать его.

Декомпиляция

При редактировании модуль декомпилируется. Отчет или форма декомпилируются при внесении лю­бых изменений, даже если они не задевают код. Создание новой формы или отчета может также декомпилировать код. Во время разработки для компиляции по необходимости можно полагаться на команду Compile on Demand (Компиляция по требованию) во вкладке General меню Tools [ Options. При этом VBA компилирует модули во время выполнения. Еще одна новая опция Access 2000 — фоновая компиляция (Background Compile). При компиляции приложения в фоновом режиме VBA освобождает разработчика от дополнительных затрат времени.

Если выполнить проверку, то оказывается, что скомпилированное приложение занимает больше дис­кового пространства, чем нескомпилированное. Причина заключается в том, что в скомпилированном приложении хранится как скомпилированный код, так и исходный. Никакого ущерба для производитель­ности здесь нет. Поскольку в память загружается только скомпилированный код, который выполняется быстрее исходного, производительность значительно повышается.

Поскольку Access постоянно загружает модули, необходимо внимательно рассмотреть все модули в данной разработке. Следует убедиться, что в приложении не осталось неиспользуемых функций или про­цедур. Необходимо удалить весь неиспользуемый код, созданный во время разработки. Если этого не сделать, компилятор будет вынужден обрабатывать невыполняемый код, а это создаст дополнительные за­держки. Кроме того, во время разработки рекомендуется время от времени закрывать окно проекта, что­бы очистить память. Даже если приложение полностью скомпилировано, должен загружаться как можно меньший объем кода.

Составление файла .MDE

Самый надежный способ удостовериться в том, что приложение остается в скомпилированном состо­янии для пользователя — это создать файл .MDE для распространения. MDE-файл не содержит исход­ного кода и не декомпилируется.

Кроме методик группировки, управления памятью и компиляции на уровне модуля, существует не­сколько специфических подходов к написанию кода, которые могут помочь создавать более быстродей­ствующие приложения.

Использование Option Explicit

Рекомендуется всегда использовать Option Explicit. Данная опция требует объявления всех переменных. Если не объявить переменную, VBA вынужден использовать самый большой и самый гибкий тип данных

для использования данной переменной. Обычно этот тип является также и самым медленным.Из сооб­ражений читабельности и целостности данных рекомендуется всегда объявлять переменную.

Выбор размеров переменных

При объявлении переменной следует использовать наименьший размер переменных из возможных. Не нужно применять двойное слово, когда достаточно применить целый тип. По возможности необходимо использовать строки фиксированной длины вместо строк переменной длины.

Сохранение стекового пространства с помощью строковых переменных

Строковая переменная — один из наиболее часто употребляемых в коде типов данных. Их можно разделить на три вида:

• Локальные фиксированной длины (не более 64 символов) — эти переменные используют два бай­та на символ и не используют область динамической памяти.

• Локальные фиксированной длины (более 65 символов) — эти строки также используют два байта на символ, но в динамической памяти. Кроме того, им нужны четыре байта в стеке для указания на переменную в динамической структуре.

• Локальные переменной длины (длина не имеет значения) —объем динамической памяти зависит от длины строки. Для указания на переменную в динамической структуре используется четыре байта стека.

При работе со строками необходимо стремиться к уменьшению объема используемого стека. Можно попытаться изменить строки на локальные строки переменной длины или на статические строки фикси­рованной длины. Ниже приведен пример строки переменной длины, объявленной как статическая стро­ка фиксированной длины для сохранения стековой памяти.