Как проводить тесты производительности на библиотеках, написанных на разных языках программирования? - PullRequest
0 голосов
/ 25 апреля 2009

Проблема в : учитывая количество программных библиотек с одинаковой или равной областью действия (например, XML-анализатор, регулярное выражение, разметка, ...); Существуют ли инструменты, с помощью которых можно запускать тесты производительности в этих библиотеках и сравнивать (и генерировать отчеты), даже если библиотеки могут быть написаны на разных языках программирования (таких как java, C #, ruby, python, perl, ...)

Я смотрел на эти opensourcetesting.org / performance.php , но ни один из них не соответствовал (несколько размытому) требованию выше.

Существуют ли наборы инструментов или интегрированные среды для кросс-платформенных тестов производительности?

Спасибо.

Ответы [ 2 ]

1 голос
/ 25 апреля 2009

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

Способности очень сильно зависят от используемого языка.

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

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

Итак, если производительность - это самое важное для вашего приложения, лучше всего сделать IMO - создать интерфейс для операций, которые вы хотите импортировать, затем подключить / отключить пару библиотек и увидеть различия в реальных тестах, тесты вашего приложения в действии, а не искусственная математика Mumbo Jumbo ...

1 голос
/ 25 апреля 2009

Я бы не стал использовать один инструментарий для нескольких языков. Это вряд ли даст лучшую (или даже среднюю) производительность для каждого приложения.

Вместо этого я бы попытался придумать дизайн фреймворка, который определяет, что он собирается тестировать, и имеет общий набор данных. Затем каждый язык / библиотека может предоставить свою собственную структуру реализацию , которая проверяет операции, подходящие для этой библиотеки. Таким образом, операции могут быть «логически эквивалентными», даже если они не используют точный тот же синтаксис / вызовы. В итоге вы тестируете идиоматический код для этой библиотеки / языка, а не просто наименьший общий знаменатель.

Это подход, который я выбрал для сравнения протокольных буферов. Пока что моя базовая среда имеет реализации на C # и Java, и сейчас я пишу более богатую среду, которая позволяет запускать целый «сценарий тестирования». Одна из идеальных целей состоит в том, чтобы разные реализации на одной и той же платформе (например, разные реализации .NET буферов протокола) могли подключаться к одному и тому же базовому коду сравнительного анализа без особых усилий.

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

...