Visual2000 · Архив статей А.Колесова & О.Павловой

Советы тем, кто программирует на Visual Basic и MS Office/VBA

Андрей Колесов, Ольга Павлова

© 1996, Андрей Колесов, Ольга Павлова
Авторский вариант. Статья была опубликована c незначительной литературной правкой в журнале "КомпьютерПресс" N 9/96, с. 70-74.


Совет 39. Тестируйте различные варианты реализации своих программ с целью выбора оптимального

На эту тему мы уже говорили ранее, рассказывая об отдельных конструкциях языка. Но данная проблема довольно обширна, поэтому нелишне обратиться к ней снова. На этот раз поводом послужила подборка материалов, опубликованная в журнале VBPJ ь 6'96 и посвященная обсуждению тестирования различных версий VB (16-разрядные VB 3.0 и VB 4.0, 32-разрядный VB 4.0) в разных условиях (Win 3.x, 95, NT; 486 и Pentium; работа с графикой, базами данных, оконным интерфейсом и численная обработка).

Мы решили познакомить наших читателей с некоторыми выводами, сделанными в этих статьях. Но прежде несколько общих замечаний.

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

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

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

Разумеется, любые исследования нужны только тогда, когда в них есть смысл. Если графический образ выводится на экран за 0,1 с, то вряд ли стоит бороться за 0,05 с. Но когда разовое обращение к базе данных выполняется за 10 с, то пользователь очень обрадуется, если время его ожидания сократится до 1 с.

Итак, некоторые выводы из статей VBPJ ь6'96.

Статья 1: Clocking Data Access (Измерение времени доступа к данным) by Steve Jackson Время выполнения запроса может варьироваться в соотношении 24:1 в зависимости от метода доступа к данным. Изучите результаты проведенных эталонных тестов для выбора необходимого вам подхода.

  1. Непосредственный вызов функций API ODBC — самый быстрый метод. Эта скорость частично обусловлена обходом Jet и DAO (Data Access Object), благодаря чему высвобождаются 2 Мбайт памяти, используемые Jet и DAO. Однако функции API намного сложнее кодировать, и код API хуже поддерживается, чем код DAO.

  2. RDO (Remote Data Object) — компромисс между ODBC API и Jet. Он намного быстрее, чем Jet и DAO, и его легче кодировать, чем ODBC API. (Но RDO существует только для 32-разрядной версии.)

  3. Идентичные 16-разрядные программы в целом выполняются немного быстрее в Win95, чем в Windows for Workgroups 3.11. Такой результат объясняется более совершенной внутренней организацией Win95 и лучшим управлением памяти, более быстрым стеком TCP/IP или двумя этими факторами, вместе взятыми.

  4. В Win95 32-разрядные приложения выполняются немного медленнее, чем 16-разрядные.

  5. В WinNT в отличие от Win95 32-разрядные тестовые программы выполняются намного быстрее, чем 16-разрядные программы. Эта разница более существенна для методов с большими непроизводительными затратами и большим числом DLL-библиотек, например таких, как метод Jet DAO, и менее существенна для методов с меньшими непроизводительными затратами, как ODBC API.

    Причина: WinNT выполняет 16-разрядные программы как отдельные задачи, называемые Windows on Windows (WOW). Поскольку WOW преобразует все вызовы 16-разрядных функций в 32-разрядные команды, он медленнее, чем Win95 или Win 3.11, которые выполняют 16-разрядные вызовы непосредственно. В NT нет 16-разрядного кода, поэтому 32-разрядный код имеет огромное преимущество.

  6. VB4 не оказывается существенно быстрее, чем VB3, для рассмотренных методов работы с БД. Большинство циклов в тестовых примерах выполняется во внутреннем компоненте (back end), а не в VB-коде, поэтому последний не является вентильным фактором (gating factor) для доступа к данным.

  7. Модернизация аппаратных средств — не единственный метод повышения скорости доступа к данным. Решение проблемы — изменить код.

Статья 2: Benchmark Battle (Борьба эталонных тестов) by Ward Hitt

VB3 побеждает VB4 в графической обработке, однако в других тестах VB4 вырывается вперед как в 16-разрядном, так и в 32-разрядном режимах.

Ключевой вопрос: если вы перейдете в Win95 или WinNT, где установлена 32-разрядная версия VB4, будут ли ваши приложения выполняться быстрее?

Ответ: все зависит от типа приложения. Для графической обработки с помощью VB-методов VB4/32 — самый медленный, а для других операций — самый быстрый. Иногда VB4 имеет ту же скорость, что и VB3.

  1. VB3 является победителем во всех графических тестах, если используются VB-методы. В Win 3.11 VB3 на 33% быстрее, чем VB4/16. В Win95 VB3 на 56% быстрее, чем VB4/16, и почти в 3 раза быстрее, чем VB4/32. VB3 убедительно лидирует и в WinNT. VB4 имеет плохие показатели в графической обработке, так как он должен подключаться (thunk) к 16-разрядному GDI.

  2. Автор рекомендует избегать графических методов в VB и вместо этого использовать вызов графических функций API. Последние резко снижают время обработки графики на 486-х компьютерах и существенно улучшают время обработки на Pentium. VB4/16 лидирует во всех тестах, использующих вызов графических функций API, за исключением WinNT, где победил VB4/32.

  3. Загрузка форм (используется во всех VB-приложениях). VB4/16 почти на 33% быстрее, чем VB3 под Win 3.11, на 15% быстрее в WinNT и медленнее как на 486, так и на Pentium в Win95. VB4/32 медленнее, чем VB4/16, загружает тестовую форму в Win95, но намного быстрее, чем VB3 или VB4/16, в WinNT. VB3 быстрее всех загружает форму в Win95.

  4. Вывод текста в элементах управления. VB4/16 в 2 раза быстрее, чем VB3, в Win 3.11, почти равен в Win95, но медленнее в WinNT. VB4/32 почти на 25% медленнее других версий в Win95, но намного быстрее в WinNT.

  5. Скорость числовых расчетов увеличивается от VB3 к VB4/16 и до VB4/32. VB4/16 быстрее, чем VB3, в Win 3.11/NT и равен в Win95. VB4/32 значительно быстрее, чем VB3 и VB4/16, за исключением конкатенации строковых переменных фиксированной длины (fixed-string). Эта операция выполняется крайне медленно в VB4/32 (второй недостаток VB!), а быстрее всего — в VB3. По неофициальным сведениям, полученным из Microsoft, данная операция представляет собой одну из целей для проведения усовершенствований в следующей версии VB.

  6. WinNT был разработан Microsoft как более надежная и помехоустойчивая система по сравнению с Win95, хотя, по-видимому, при этом была принесена в жертву скорость вывода. Тем не менее, числовые расчеты (number crunching) выполняются быстрее в NT, чем в Win95.

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

  8. В целом версии VB4 примерно равны или лучше, чем VB3, для Win95 или NT. Если вы работаете в Win 3.11 с 8 Мбайт оперативной памяти, VB3 по-прежнему является хорошим средством разработки.

В начало статьи

Совет 40. Минимизируйте количество повторяемых перекодировок OLE

Используйте оператор With...End With для минимизации количества повторяемых перекодировок OLE. Этот способ имеет дополнительное преимущество: он не требует временного объекта для подстановки.

В начало статьи

Совет 41. Используйте in-process серверы при любой возможности

Для повышения производительности используйте in-process серверы (в виде библиотек OLE DLL), когда это только возможно. Выполнение вызовов объектов внутри пространства приложения — либо в самом приложении, либо в in-process сервере — осуществляется намного быстрее, чем вызовы объектов за пределами пространства приложения.

В начало статьи

Совет 42. Как ускорить вызовы OLE-сервера

Передавайте как можно больше данных в/из OLE-сервера за каждую операцию вызова. Передача данных выполняется быстро, а операция вызова — медленно, особенно когда вы имеете дело с out- of-process серверами. Например, вы можете передать набор параметров в массиве, вместо того чтобы вызывать OLE-сервер несколько раз.

В начало статьи

Совет 43. Инициализация DLL-библиотеки, представленной в виде in-process OLE-сервера

Запустите in-process OLE-сервер с помощью процедуры Sub Main. Включите в нее код инициализации всех серверов. Не выводите на экран формы из этой процедуры и не используйте Command Function для получения содержимого командной строки (она не существует при инициализации in-process сервера).

В начало статьи

Совет 44. Тестирование DLL-библиотеки, представленной в виде in-process OLE-сервера

Чтобы протестировать DLL-библиотеку в виде in-process OLE-сервера, сначала постройте ее в виде out-of-process сервера. Это существенно упрощает операции отладки и тестирования. Имейте в виду, что in-process сервер также будет влиять на стабильность всего приложения. Поэтому хорошей идеей является обеспечение стабильности OLE-сервера в виде out-of-process сервера, а затем уже преобразование его в DLL-библиотеку OLE.

В начало статьи

Совет 45. Тестируйте in-process OLE-сервер как out-of-process сервер

Используйте опцию OLE Restrictions для тестирования in-process OLE-сервера как out-of-process сервера. Данная опция находится во вкладке Advanced диалогового окна Options. Она активизирует ограничения DLL, хотя вы и используете out-of-process сервер. Такой подход эффективен при проверке работы сервера в качестве in-process сервера.

В начало статьи

Совет 46. Как выгрузить сервер из памяти

Закройте экземпляр Visual Basic, который использует скомпилированный in-process OLE-сервер, чтобы выгрузить этот сервер из памяти. Изменения в in-process OLE-сервере не будут видны до тех пор, пока текущая версия сервера не будет выгружена из памяти, а новая загружена.

В начало статьи

Совет 47. Как установить MousePointer в in-process OLE-сервер

Не устанавливайте MousePointer в библиотеку OLE DLL до тех пор, пока полностью не убедитесь, что это необходимо. In-process OLE-сервер не может осуществить поиск текущего курсора мыши, поэтому у вас нет возможности установить его обратно в то состояние, которое требуется приложению. Если все же необходимо установить MousePointer в in-process OLE-сервер, всегда устанавливайте его в значение по умолчанию перед тем, как вернуть в клиентское приложение. Если клиентское приложение имеет другой набор MousePointer, тогда оно должно вернуть MousePointer в необходимое состояние после обращения к какому-либо свойству или методу сервера.

В начало статьи

Совет 48. Как передать массив элементов управления

Работа с массивами элементов управления в VB3 была сплошной нервотрепкой, но в VB4 появилась возможность передавать такой массив в качестве аргумента функции. Для этого необходимо просто указать тип параметра как Variant:

Private Sub Command1_Click(Index As Integer)
   GetControls Command1()
End Sub
Public Sub GetControls(CArray As Variant)
  Dim C As Control
  For Each C In CArray
    MsgBox C.Index
  Next
End Sub

Кроме того, массивы элементов управления в VB4 имеют свойства Lbound, Ubound и Count:

If Command1.Count < Command1.Ubound - Command1.Lbound + 1 Then_
     MsgBox "Массив не является непрерывным" 

В начало статьи

VB 5.0 — хорошие новости для России

В начале июня в Обнинске прошла очередная российская конференция Microsoft для разработчиков — DevCon'96. На ней была официально объявлена следующая информация. В версии 5.0 будет реализован настоящий транслятор, создающий не менее настоящие исполняемые модули на машинном языке! В VB 5.0 будут наконец-то реализованы все основные элементы объектно-ориентированного языка, а не какие-то псевдообъекты в виде элементов управления и классов (то, как они понимались в VB 4.0). Как уже сообщалось ранее, у VB- программистов появится возможность создания OCX на этом же языке.

Версия VB 5.0 будет локализована для России! Работа по локализации будет вестись параллельно с общей подготовкой к новой версии (фактически — это этап начинающегося бета- тестирования), и локализованную версию планируется выпустить практически одновременно с основной, американской, осенью этого года.

Локализация будет проходить по схеме, уже применявшейся для других систем программирования (в частности, для Visual FoxPro): будет переводиться только документация и справочная система, программная же часть пакета останется неизменной. Но при этом в ходе доводки VB 5.0 до окончательного варианта особое внимание будет уделяться возможности работы VB с кириллицей. Это касается проблем ввода-вывода русских букв, сортировки символьных данных и пр.

Бета-тестирование уже началось. Сейчас в нем участвуют две российские фирмы (Microsoft не сообщает о конкретных участниках тестирования, как и об исполнителях локализации). На этот раз число бета-тестировщиков резко сокращено — это общая политика фирмы во всем мире. Через два месяца, на следующем этапе тестирования, число участников может быть расширено. По заявлениям представителей Microsoft, прозвучавшим не только на DevCon'96, но и в международной прессе, роль VB как стратегического направления средств разработки будет расти и в дальнейшем. В частности, фирма называет именно его, а также его подмножество VBScript в качестве основной системы, которая составит альтернативу Java. Уже известно, что многие будущие расширения VB связаны с работой в Internet.

Другая тенденция — расширение возможностей работы с базами данных. В частности, на DevCon'96 прозвучало следующее: Microsoft планирует прекратить развитие направления FoxPro как самостоятельного средства разработки и интегрировать его с Visual Basic. Тем не менее, этой осенью выйдет новая версия Visual FoxPro 5.0 (сразу после прошлогодней 3.0), возможно, через год-полтора появится еще одна версия, которая, скорее всего, будет последней. По крайней мере, таковы намерения Microsoft на сегодня.

Известие о такой судьбе FoxPro, естественно, взволновало его многочисленных отечественных пользователей. Однако представители Microsoft призывали их не огорчаться, выдвигая следующие аргументы:

Заметим, что старые версии систем разработки действительно не умирают с выходом новых. По некоторым оценкам, большинство пользователей FoxPro (причем не только для России) продолжают работать с версиями 2.x, хотя Visual FoxPro появился еще два года назад. С другой стороны, опыт показывает, что любые планы могут корректироваться в обоих направлениях — скорее версия 6.0 не будет выпущена вообще, чем появится 7.0. В любом случае очевидно, что разработчикам FoxPro есть над чем подумать. Что же касается VB-программистов, то их такая информация заметно обрадовала, так как она свидетельствует о хороших перспективах развития этой системы, которая в настоящее время в некоторых вопросах даже обычного программирования (например, использования объектно- ориентированных средств) значительно уступает Visual FoxPro.

В начало статьи