Здравстуйте, товарищи программисты и товарищи не программисты!

Всвязи с тем, что тема медленности JAVA машин имеет противоречитую и спорную ситуацию, у меня возникла идея создать программу для её тестирования.
Программа будет работать подобно 3D Mark- у, который гоняет видеокарту на полную катушку, а потом выставляет оценку, но только тестировать будем не видеокарту, а JVM. Подобные тесты помогли бы выявить зависимость производительности JVM как от операционной системы, так и от железа. Мне кажется, что подобная программа лучше поможет оценить производительность системы, выявить слабые места или просто провести сравнение с другой системой. Тем более просто интересно насколько целесообразно использовать какой-либо алгоритм учитывая скорость выполнения стандартных операций.

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

Если Вам интересна эта идея, то предлагаю постить сюда ваши предложения и примеры тестов. И со временем, дружно, отберем и доработаем лучшие тесты. А потом выложим как общественное достояние под флагом Винграда. Думаю это будет весьма гордо.

Если Вы считаете разработку такой программы не целесообразной, совершенно бесполезной или ей существуют аналоги, то пожалуйста, все ссылки и аргументы в сюда.
С Уважением, MoonCat.

Это сообщение отредактировал(а) MoonCat - 8.2.2006, 15:27

Для этого есть специальный раздел: Наши тесты.

Считаем целесообразной и очень полезной


Да, хорошая идея. Хорошое начало необходимо только. Первым делом предлагаю потестить сложение строк в яве

Согласен. Есть такой раздел. Но все дело в Java. Именно поэтому я здесь тему и накатал.
Lamer George, если желаешь, премещай тему в Наши Тесты, но сюдя по посещаемости этого раздела она там быстро заглохнет. А здесь как никак Java кодеры постоянно.....



Несомненно такой тест будет. Я думаю еще можно создать тесты на пересылку строк, на создание строковых объектов, на поиск в строках. На тему строк можно немало интересных тестов написать.....

Я думаю сначало общими усилиями Ваши предложения и примеры тестов. Хотелось бы обсудить каждый из тестов, понять результаты каждого теста. Пишите примеры, объясняйте как с помощью Вашего теста можно оценить производительность системы. Потом можно будет создать ядро системы тестирования, подключать и новые виды тестов и анализоровать результаты!
Так же очень приветствуется обсуждение и предложения по работе системы в целом и по анализу результатов.
PS: Не обязательно спешить кодить, здесь придется сначало подумать...

Потому и не перенес пока. Если раскрутится, тогда перенесем (может быть).
Добавлено @ 17:23
Закрепляю тему.

Спасибо!!!

[offtopic]

[/offtopic]
Это новый вариант подписи? ))

Я недавно закидывал кусочек кода - сравнивал LinkedList и ArrayList.
В каком-то топике Wowы. Кажется с логгированием что-то.
Можно добавить туда прочих прочестей.

Готов предоставить свою тачку под Федорой 4 и виндой ХаРе для тестов

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

Это сообщение отредактировал(а) MoonCat - 8.2.2006, 18:10

Это я ещё тогда хотел сделать - руки не дошли. Постараюсь вскорости.
Кстати, "маленькие классы", ту же идею проповедуют
Можно в этом Vingrad SDK сделать пэкэдж:
ru.vingrad.tests.collections
ru.vingrad.tests.strings
Если уж собирать - то собирать всё до кучи.
Lamer George говорил что с организацией сего(куда складывать, как организовывать) ещё всё обдумается.
Можно сделать тему SDK с древовидными подтемами, отображающими структуру этого SDK. Одна такая корневая тема - куда будут закидывать. Вторая - куда будут переноситься ТОЛЬКО модераторами одобренные и проверенные решения(из первой затираться)

Это сообщение отредактировал(а) chief39 - 8.2.2006, 18:49

Были бы тесты, а организацию перелопатить никогда не поздно. Имхо, пока можно и в кучу складывать.

Ну эт так.... тяга к порядку )) Ок. Договорились

По скоростных характеристикам придумать тесты не так уж и сложно. Например берем Н.Вирт Алгоритмы и структуры данныхили Д.Кнут Исскуство программирования, и вот тебе готовые алгоритмы. вопрос кто будет их реализовывать.

Бумажная? Или ссылка есть под рукой?


Я постараюсь, просто сейчас исп. срок на новой работе заканчивается - приходится напрягаться, да и сезон урожайный

Ну начинается, немедленно идем в настройки отображения форумов и открываем Компьютерную литературу
Вот топик с этими книгами.

Да и по другим темам тоже. Тесты это процесс времени. Пусть они потихоньку обдумываются, выкладываютс сюда.
Но вот правила написания тестов и общую организацию системы хочется обсудить сразу. Далее я привел некоторые мысли на эту тему, с целью более конкретного понимая общественностью, того, к чему, на мой взгляд, это всё должно стремится. Ваши добаления, критика, вопросы - все обсуждаем. Это первая ( и наверное, непоследняя) попытка описать общие положения о работе системы.

//----------------------------------------------------------------------------------------------------------------------------------------------------
Основные концепции организации системы тестирования JVM.
Система структурно состоит из двух основных частей:
1) Менеджер тестов.
2) Тест.
Существут только один менеджер тестов (МТ). МТ – главная, управляющая часть системы.
МТ должен выполнять след. действия:
1) Подключение/отключение теста.
2) Настройка теста с использованием графического интерфейса.
3) Запуск теста на выполнение.
4) Обработка и отображение результатов теста.
5) Автоматизация выполнения серии тестов.
6) Прочие функции для контроля и настройки системы тестирования.
Существует много тестов. Тест представляет собой подключаемый, к МТ, уникальный модуль. Тест должен выполнять след. действия:
1) Предоставить объекты для настройки теста, как графическим, так и программным образом.
2) Предоставить возможность контроля за выволнением теста.
3) Формирование результатов теста.
4) Хранение описания теста.
5) Выполнение теста.
Хочется отметить несколько особенностей системы:
1) Тест должен иметь возможность выполнения без процесса начальной настройки, т. е. используя настройки по умолчанию.
2) Тест должен предоставить МТ GUI Компонент настройки, а МТ в свою очередь обеспечить контейнер для отображения и выполнения графической настройки теста.
3) МТ должен иметь серию стандартных тестов, которые поставляются вместе с ним.
4) МТ должен иметь систему оценки результатов тестов, а также возможность сохранения ее в файл (возможно, в базу данных).
//----------------------------------------------------------------------------------------------------------------------------------------------------

кстати, имеется Кнут, первые 202 страницы 3-го тома в pdf (1,4 мб), могу куда-нибудь за upload-ить

Это сообщение отредактировал(а) MoonCat - 9.2.2006, 21:09

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

ВСЕ ЧТО Я ПИШУ ПО ЭТОЙ ТЕМЕ, ЛИШЬ МОЕ СКРОМНОЕ ЛИЧНОЕ МНЕНИЕ. Я УВАЖАЮ И ПРИСУШИВАЮСЬ К МНЕНИЮ ДРУГИХ ЛЮДЕЙ, КОТОРЫЕ ЖЕЛАЮТ РАЗВИТИЯ ДАННОГО ПРОЕКТА. ЕСЛИ У ВАС ЕСТЬ ИДЕИ ПО СОВЕРШЕНСТВОВАНИЮ ДАННОЙ СИСТЕМЫ, ТО ПОЖАУЙСТА, НЕ МОЛЧИТЕ. ВСЕ ПРЕДЛОЖЕНИЯ БУДУТ РАССМОТРЕНЫ И ПРИНЯТЫ ДОЛЖНЫМ ОБРАЗОМ. (это я так, на будущие).

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



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

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

Я еще раз все перепродумаю, и попробую написать небольшой пример на эту тему.

Сорри за , но куда еще написать не знаю, всетаки немного к этой теме относится......
Я пример написал, маленькой системы управления тестами (с плагинами) , демонстрирующий мои мысли изложенные ранее, но как файл залить на форум не нашел.... Вы уж ногами не бейте, ткните носом, где тут такая возможность поддерживается.......

Это сообщение отредактировал(а) MoonCat - 14.2.2006, 21:11

Если небольшой, то можно прикрепить файл через форму ответа (по кнопке "Ответить", она среди кленовых листочков).

А если большой (более 50К), то вышли мне я прикреплю.

Хм. Если тест проводится с собственным гуем, это повлияет на скорость, имхо, весьма значительно.
В .NET можно было бы использовать компонент PropertyGrid для задания свойств теста перед его выполнением, а тут вроде аналогов нет..
Добавлено @ 00:58
Кстати, предлагаю запускать тесты в отдельном потоке от гуя. А то тормозить страшно будет при объемных тестах.

Больше 50k, чиркни свой майл пожалуйста, я вышлю.



А как это повлияет на скорость теста? ИМХО, JVM придется только памяти выделить под компонент настройки и все.
Тест действительно будет выполняться в отдельном потоке, возможно, приоритет которого можно даже будет настроить.

Вообщема так, мое ИМХО

ГУЙ конечно ресурсы будет жрать и не только память, самое противное это перерисовка компонент. Она может неожиданно возникать и портить нам всю малину, в виде всплесков потребления процессорных ресурсов. Соответсвенно результаты могут плавать, что не есть хорошо. Да и для повторения теста на другой машине придется описывать какие параметры, куда забиваются. Плюс для какждого теста писать свой конфигуратор. Из-за всего этого мне и не нравится идея с ГУЕМ.

Я предлагаю работать, через конфигурационные файлы. За образец я бы взял конфигурационные файлы log4j. Маленький примерчик для тех кто не знаком:

Здесь мы указываем имя класса: org.apache.log4j.DailyRollingFileAppender, который надо создать, и имя property которые надо установить: File, Append, DatePattern и значения для них. Плюс общие настройки. Таким макаром можно один раз написать систему тестирования и больше ее не переписывать. И проблем с конфигурированием тоже нет, переслать конфигурационный файл, пара пустяков.

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



Интересная идея! Но сожалению я плохо понимаю как это все работает. Было очень инересно прочитать продолжение этой идеи и (если можно) с ответами на эти вопросы:

1) Как определить какие настройки поддерживает тест. (Включая типы значений и допустимые
диапазоны значений)?
2) Как создать графический настройщик для определенного теста?
3) Как проверить корректность настройки?

P.S.
GUI настройщик легко решает все эти проблемы, требуя лишь немного больше память, которую кстати можно ухитрившись освободить, но придется разделить Компонент Тест на ВИД и МОДЕЛЬ,
а Вид освобождать после настройки. Это добавит еще гибкости. И кстати ничто не мешает сохранять настройки теста в файл самостоятельно, а потом загаружать их на другой машине.
Вообще, используя GUI настройщик для каждого класса, мы поддерживаем чистый компонентный подход в разработке проекта. Поддерживаем идею, когда каждый может написать чать Системы Тестирования JVM, и не только закодировать тетст, но и добавить к нему свое оформление, которое придаст ему иникальности.

Я легко откажусь от своей идеи с GUI настройщиком, если будет то, что сможет по гибкости и простоте его заменить.........

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

Всмысле сначало настраиваем ряд тестов, сохраняем сценарий в файле xml, освобождаем память
от ненужных GUI и выполняем тест только на рабочих тест-компонентах?

Одна проблема безгуевого решения -- невозможность узнать прогресс. Как вариант -- перед стартом теста действительно показывать некий гуй, определенный компонентом, а потом попросту отображать прогрессбар, который периодически обновляется. Прогрессбар берет свое значение от некой функции GetCompletedPercentage, которую обязан реализовать каждый тест.

Гуй в пень.

Могикане считали, что нетерпеливость простительна женщинам, но не мужчинам, подождут

Disclaimer: поскольку MoonCat не может прикреплять большие файлы, это делаю я, весь последующий текст, это его комментарий к коду:

============8<============8<============8<============8<============8<============

Вот небольшой пример на тему раннее изложенных мною мыслей.
Программа с MDI интерфейсом, имеет 3 основных части:
1) Главное окно.
2) Менеджер (загрузчик) плагинов. ( Отображает список доступных плагинов и загружает их в Контейнер настройки плагина ).
3) Контейнер настройки плагина. (выполняет интерфейс настройки плагина).

Вы можете компилировать исходники любым удобным для Вас способом.
К сообщению прикреплен архив с 2 проектами в формате NetBeans 5.0, если у кого стоит такой, то можно прямо им и рулить. А можно все ручками.

Первый проект - это Сисема Выполнения Тестов, второй - плагин, на примере сортировки. Ознакомьтесь со структурой файлов в архиве distrib.zip. После того как сами скомпилируете файлы воссоздайте такую же структуру. Если не хотите компилировать сами, то запускайте готовый, но он работать будет на jre1.5.0_06.

Вот еще краткие замечания по сборке:
Функционально программа состоит из двух частей: Система тестирования (Poseidon.jar + lib/swing-layout-1.0.jar) и плагин ( папка lib/ru/...).

Вот состав архива Poseidon.jar после компиляции:
META-INF\MANIFEST.MF
frames\MainFrame$1.class
frames\MainFrame.class
frames\ManageInternalFrame$1.class
frames\ManageInternalFrame$2.class
frames\ManageInternalFrame.class
frames\SettingsContainer$1.class
frames\SettingsContainer$2.class
frames\SettingsContainer$3.class
frames\SettingsContainer.class
ru\vingrad\java\poseidon\PoseidonTest.class

В манифесте (META-INF\MANIFEST.MF) параметр "Class-Path: lib/ /lib/swing-layout-1.0.jar" - должен выгладеть так (но без кавычек), чтобы программа нашла расположенные там плагины и библиотеки. Гланый класс - MainFrame.class.

Папка lib должна выглядеть так:
ru\vingrad\java\poseidon\plugins\sort\SortLibrary.class
ru\vingrad\java\poseidon\plugins\Sort.class
ru\vingrad\java\poseidon\plugins\Sort$1.class
ru\vingrad\java\poseidon\plugins\Sort$2.class
ru\vingrad\java\poseidon\PoseidonTest.class

Здесь
PoseidonTest.class - Интрефейс, который должен поддерживать каждый плагин.
Sort.class - Плагин, реализующий интерфейс PoseidonTest и наследованный от JPanel
SortLibrary.class - Библиотека алгоритмов сортировки, которую использует плагин Sort.

Когда скомпелируете плагин, добавьте его файлы, а вернее все файлы из папки ru/... в папку lib/plugins/ , которая находится в одной папке с Poseidon.jar. Запускайте Poseidon.jar из папки в которой он находится, если хотите чтобы все заработало.

(Кстати, Все исходки прокоментированны. На все вопросы постараюсь ответить.)

Что будет после запуска программы.
Появится главное MDI окно, в котором будет окошко менеджера тестов. Лист в окне менеджера тестов должне содержать один элемент - Sort. Выберите и загрузите его. Если все настроено правильно, то загрузится контейнер настроек, с элементом настройки теста Sort. Тест можно будет настроить и выполнить. Поэспериментируйте с программой.

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

Прикрепленные файлы: distrib.zip, Poseidon.zip, Sort.zip.

============8<============8<============8<============8<============8<============

Я рекомендую обратить особое внимание не интерфейс, который является базовым для всех плагинов (PoseidonTest). Возможно будут мысли разбить его на несколько или добавить в него еще какие нибудь методы, your are welcome

Ваши альтернативы ???

MoonCat, Запуск из командной строки + xml-конфиги. А вот уже потом, если захочется, можно вокруг всего этого дела навесить гуй. И вообще. Столько много шума по поводу того, какими рюшечками всё обвешать, но пока почти ничего про то, что собственно тестировать и как сравнивать.

к вопросу о гуях и не только.

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

Примеры:
захотелось винде обновиться...
антивирус на дискетту полез...
и т.д. и т.п. ...

как предлагаете с этим бороться или учитывать?

Было бы неплохо увидеть какой-нибудь примерчик на эту тему.......



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

P.S: Вот например Майкрософт, создала специальную программу, которая загружает процессор "по полной программе", и каждый разработчик может проверить работу своего софта, так сказать, в экстимальных условиях.....

Это ты про новый Windows?

[offtopic]
Если меня не подводит память, я читал про существование этой проги вот в этой книге
http://anatolix.naumen.ru/Books/InsideWind...00?show_files=1
соответственно под Windows 2000
[/offtopic]

Это сообщение отредактировал(а) MoonCat - 17.2.2006, 16:52

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


Я над этим работаю.

MoonCat, примерчик командной строки? Или xml-конфига?

Не о том думаете, парни. Надо думать о том, ЧТО тестировать.

Хмм,
http://www.spec.org/jbb2005/press/release.html

информационно.

А JVM6 еще не тестировали? 

Не имеет смысла, пока стабильная версия не выйдет. 

Вот тут есть темка про скорость - http://forum.vingrad.ru/index.php?showtopic=115514
Действительно Java 1.6 стала заметно быстрее по сравнению с 1.5. 

спасибо. было интересно.

Тема откреплена.