Visual2000 · Архив статей А.Колесова & О.Павловой
Андрей Колесов, Ольга Павлова
© 1996, Андрей Колесов, Ольга ПавловаНа эту тему мы уже говорили ранее, рассказывая об отдельных конструкциях языка. Но данная проблема довольно обширна, поэтому нелишне обратиться к ней снова. На этот раз поводом послужила подборка материалов, опубликованная в журнале 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 в зависимости от метода доступа к данным. Изучите результаты проведенных эталонных тестов для выбора необходимого вам подхода.
Причина: WinNT выполняет 16-разрядные программы как отдельные задачи, называемые Windows on Windows (WOW). Поскольку WOW преобразует все вызовы 16-разрядных функций в 32-разрядные команды, он медленнее, чем Win95 или Win 3.11, которые выполняют 16-разрядные вызовы непосредственно. В NT нет 16-разрядного кода, поэтому 32-разрядный код имеет огромное преимущество.
Статья 2: Benchmark Battle (Борьба эталонных тестов) by Ward Hitt
VB3 побеждает VB4 в графической обработке, однако в других тестах VB4 вырывается вперед как в 16-разрядном, так и в 32-разрядном режимах.
Ключевой вопрос: если вы перейдете в Win95 или WinNT, где установлена 32-разрядная версия VB4, будут ли ваши приложения выполняться быстрее?
Ответ: все зависит от типа приложения. Для графической обработки с помощью VB-методов VB4/32 — самый медленный, а для других операций — самый быстрый. Иногда VB4 имеет ту же скорость, что и VB3.
Используйте оператор With...End With для минимизации количества повторяемых перекодировок OLE. Этот способ имеет дополнительное преимущество: он не требует временного объекта для подстановки.
Для повышения производительности используйте in-process серверы (в виде библиотек OLE DLL), когда это только возможно. Выполнение вызовов объектов внутри пространства приложения — либо в самом приложении, либо в in-process сервере — осуществляется намного быстрее, чем вызовы объектов за пределами пространства приложения.
Передавайте как можно больше данных в/из OLE-сервера за каждую операцию вызова. Передача данных выполняется быстро, а операция вызова — медленно, особенно когда вы имеете дело с out- of-process серверами. Например, вы можете передать набор параметров в массиве, вместо того чтобы вызывать OLE-сервер несколько раз.
Запустите in-process OLE-сервер с помощью процедуры Sub Main. Включите в нее код инициализации всех серверов. Не выводите на экран формы из этой процедуры и не используйте Command Function для получения содержимого командной строки (она не существует при инициализации in-process сервера).
Чтобы протестировать DLL-библиотеку в виде in-process OLE-сервера, сначала постройте ее в виде out-of-process сервера. Это существенно упрощает операции отладки и тестирования. Имейте в виду, что in-process сервер также будет влиять на стабильность всего приложения. Поэтому хорошей идеей является обеспечение стабильности OLE-сервера в виде out-of-process сервера, а затем уже преобразование его в DLL-библиотеку OLE.
Используйте опцию OLE Restrictions для тестирования in-process OLE-сервера как out-of-process сервера. Данная опция находится во вкладке Advanced диалогового окна Options. Она активизирует ограничения DLL, хотя вы и используете out-of-process сервер. Такой подход эффективен при проверке работы сервера в качестве in-process сервера.
Закройте экземпляр Visual Basic, который использует скомпилированный in-process OLE-сервер, чтобы выгрузить этот сервер из памяти. Изменения в in-process OLE-сервере не будут видны до тех пор, пока текущая версия сервера не будет выгружена из памяти, а новая загружена.
Не устанавливайте MousePointer в библиотеку OLE DLL до тех пор, пока полностью не убедитесь, что это необходимо. In-process OLE-сервер не может осуществить поиск текущего курсора мыши, поэтому у вас нет возможности установить его обратно в то состояние, которое требуется приложению. Если все же необходимо установить MousePointer в in-process OLE-сервер, всегда устанавливайте его в значение по умолчанию перед тем, как вернуть в клиентское приложение. Если клиентское приложение имеет другой набор MousePointer, тогда оно должно вернуть MousePointer в необходимое состояние после обращения к какому-либо свойству или методу сервера.
Работа с массивами элементов управления в 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 "Массив не является непрерывным"
В начале июня в Обнинске прошла очередная российская конференция 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.