Visual2000 · Архив статей Колесова & Павловой
Андрей Колесов
© 1997, Андрей КолесовХотя данная статья написана в начале 1997 года и в ней говорится о версиях нескольких инструментов той поры, она может быть полезна разработчикам и сегодня, так как здесь рассматриваются некоторые методические вопросы тестирования и анализа его разультатов. Именно поэтому в отличие от ранее опубликованного варианта статьи, сначала идет мой комментарий, а уже потом — описание самого теста.
Любой сравнительный анализ чего бы то ни было (программ, компьютеров, пылесосов и пр.) даже при использовании вроде бы объективных, численных показателей грешит субъективностью. Прежде всего при всей "обобщенности" теста он является лишь некоторым отражением конкретной задачи: показания на реальном примере могут существенно отличаться от тестовых. Кроме того, любая система имеет свои преимущества и недостатки. В этой ситуации довольно легко вольно или невольно сделать крен в ту или иную сторону.
Тем более сложно сравнивать средства разработки. Дело в том, что они зачастую не имеют точных аналогов программных конструкций или, по крайней мере, имеют разные варианты реализации одних алгоритмов. Причем сравнительные характеристики двух вариантов тестов для различных систем могут быть противоположны с точностью до наоборот. На эту тему можно говорить много, но достаточно только упомянуть, что даже реализация одной задачи одним инструментом, но разными программистами может различаться весьма существенно.
Для чего нужен анализ производительности? Наверное, для выбора инструмента разработки. Но очевидно, что производительность (как и стоимость) — не единственный и не самый главный критерий такого выбора. Возможно, более важным является опыт разработчика, наличие наработок и пр.
Инструмент разработки выбирается на довольно значительный срок и часто, меняя версии, программист пользуется им долгие годы. Даже если в новой версии одна система опередила другую, отнюдь не означает того, что нужно срочно расставаться с инструментом, хотя бы потому, что через год все может измениться. Но принять во внимание подобный факт имеет смысл.
В плане долгосрочного выбора представляется более целесообразным разобраться в общих принципах позиционирования данного инструмента в долгосрочной перспективе, причем как с точки зрения заложенных в нем базовых архитектурных решений, так и стратегии его развития его создателем. Так, использование разных принципов работы со строковыми переменными изначально предопределяет преимущество Delphi перед VB по быстродействию (но при этом несколько упрощает разработку на VB). А отсутствие компилятора в первых четырех версиях VB отражало лишь некоторую принципиальную позицию Microsoft, которая просто не хотела его делать по своим соображениям (во всех последних DOS-овских системах Microsoft Basic компилятор был).
И тем не менее, несмотря на приведенные выше предостережения, любые данные о тестировании продуктов безусловно представляют большой интерес, даже если вы не собираетесь выбирать или менять инструмент немедленно. Например, это хороший повод утвердиться во мнении "Правильной дорогой идете, товарищи!" или произнести ту же фразу, но уже как вопрос.
Возможно, результаты тестов покажутся не соответствующими вашему опыту работы с собственными разработками. В этом случае не спешите ругать авторов теста: может быть, разумнее посмотреть на свои программы — нет ли там проколов с вашей стороны?
Данный анализ является кратким изложением технического отчета фирмы Carnegie Technologies, Inc. от 21 января 1997 г.
Carnegie Technologies (г. Атланта, США) — консультационная компания, специализирующаяся в области информационных технологий. Ее подразделение по исследованию производительности программного обеспечения специализируется в моделировании производительности приложений "клиент/сервер".
Эталонный тест производительности — Q1 предназначен для измерения быстродействия современных компилирующих средств разработки приложений "клиент/сервер". Он определяет эффективность приложений по четырем показателям: графический вывод, доступ к базам данных, технология OLE Automation и язык, и объединяет три теста для графического вывода, три теста для доступа к базам данных и четыре теста для измерения производительности технологии OLE Automation. Кроме того, комплект тестов Q1 содержит два раздела, служащих для эмуляции кода реальных приложений. В них включены типичные операции программирования — числовые вычисления, передача управления, выполнение цикла, динамическое распределение памяти (через строки и массивы переменной длины), а также функции для обработки строк.
Ниже приведены результаты тестирования для четырех 32-разрядных средств разработки в среде Windows 95: Visual Basic 5.0, Visual Basic 4.0 (в режиме интерпретации), Delphi Client/Server 2.0 и PowerBuilder 5.0.
Результаты тестирования по стандарту Q1, мс
| Тесты | Visual Basic 5.0 | Visual Basic 4.0 | Delphi 2.0 | PowerBuilder 5.0 |
| Операции вывода | ||||
| Пустой вывод | 52.509 | 68.677 | 26.851 | 85.667 |
| Метки | .316 | .755 | 1.295 | 4.748 |
| Растры | 1.226 | 2.42 | 3.296 | 8.925 |
| Базы данных | ||||
| Общие затраты | 9.745 | 22.234 | 7.838 | 6.935 |
| Небольшая выборка | .340 | 1.415 | .612 | .393 |
| Большая выборка | .251 | .218 | .110 | .161 |
| OLE Automation | ||||
| In Process установка (Let) | .000294 | .000648 | .084 | N/A |
| In Process обращение (Method) | .000295 | .000482 | .082 | N/A |
| Out of Process установка | 1.066 | 1.439 | 2.572 | N/A |
| Out of Process обращение | 1.039 | 1.388 | 2.572 | N/A |
| Язык | ||||
| "Решето Эратосфена" | 360.625 | 5622.43 | 3323.82 | 16940.12 |
| Обработка строк | 900.35 | 1463.990 | 48.13 | 1941.360 |
Примечание. Приведенные в таблице значения представляют собой среднее время на выполнение единичной операции, измеренное в миллисекундах. Каждый тест согласуется с 95-процентным доверительным интервалом, который представляет собой менее 1% среднего значения для данного теста. Другими словами, любой тест можно повторно выполнить с 95-процентной вероятностью получения результата, отличающегося от приведенного в отчете значения на 1%.
Как видим, что VB 5.0 обеспечивает чрезвычайно эффективную компиляцию кода для задач, связанных со значительным объемом вычислений. Пример теста "Решето Эратосфена" показывает, что VB 5.0 почти в 10 раз быстрее по сравнению с Delphi и почти в 50 раз быстрее, чем PowerBuilder. VB 5.0 продемонстрировал самую высокую производительность в 8 из 12 тестов, а в двух других занял второе место.
PowerBuilder был самым медленным в большинстве тестов, однако лидировал по результатам тестирования общих затрат при работе с базами данных (время установки обращения к базе данных). Delphi показала приличное время по большинству тестов, но очень медленно выполняла удаленные вызовы в режиме in process OLE Automation. При этом Delphi оказалась наиболее эффективным языком для обработки строк, что, вероятно, объясняется лежащей в ее основе архитектуре управления строками и памятью.
VB 5.0 по всем параметрам превосходит VB 4.0. Наиболее впечатляющие результаты были достигнуты в тесте "Решето Эратосфена", измеряющем скорость управляющей логики и числовых вычислений; здесь VB 5.0 обогнал VB 4.0 более чем в 15 раз (вполне естественно для сравнения компилятора и интерпретатора).
Некоторые выводы:
Обратите внимание: реализация байтового массива в VB должна была бы увеличить его производительность, однако в текущей версии отсутствуют встроенные функции работы с ними.
Здесь необходимо сделать одно немаловажное предупреждение. Производительность приложения является не единственным критерием при выборе какого-либо средства разработки. Ниже перечислены другие показатели, которые необходимо принимать во внимание:
Эти показатели вместе с эффективностью выполнения кода составят сбалансированный набор критериев выбора средств для разработки приложения со стороны клиента.