Что нового

Сравнение скорости Autoit Vs VB 2008 .Net

Ketoz

Новичок
Сообщения
4
Репутация
3
Решил испытать скорость Autoit относительно Visual Basic 2008 .Net, может кому-то будет интересно.

Для тестирования составил аналогичный код на двух языках.
Для Autoit провел три вида тестов - № 1 и 2 - по три запуска каждый, 3 тест один запуск, больше запускать не захотел :smile:.
Для VB .Net провел 4 вида тестов по три запуска каждый.
Максимальное сходство кодов достигается в 1 и 2 тестах с VB Net. В них используются медленные переменные и массивы типа Object, которые, кстати, в нормальном коде почти не употребляются.
Коды 3 и 4 VB Net привел для сравнения, в них используется достаточно быстрые переменные и массив типа Integer, которые скорее всего и использовались бы в реальных приложениях.
В тесте 3 у Autoit и VB Net использовал 100 млн. итераций цикла, т.к. VB Net показывал 0 мс. при 10 млн. итераций.

Тесты:
Autoit тест 1 (присвоение значения переменной 10 млн. раз):

Код:
Dim $Test  = 0
Dim $N = TimerInit()
For $i = 1 To 10000000
	$Test = $i
Next
MsgBox(0, "Прошло", TimerDiff($N))


Результаты: 7234 мс., 7255 мс., 7197 мс.


Autoit тест 2 (заполнение массива длиной 10 млн. элементов):

Код:
Dim $Test[10000000]
Dim $N = TimerInit()
For $i = 0 To 9999999
	$Test[$i] = $i
Next
MsgBox(0, "Прошло", TimerDiff($N))


Результаты: 28307 мс., 28288 мс., 28268 мс.


Autoit тест 3 (присвоение значения переменной 100 млн. раз):

Код:
Dim $Test  = 0
Dim $N = TimerInit()
For $i = 1 To 100000000
	$Test = $i
Next
MsgBox(0, "Прошло", TimerDiff($N))


Результаты: 71845 мс.



VB 2008 .Net тест 1 (присвоение значения переменной типа Object 10 млн. раз):

Код:
Dim Test As Object = 0
Dim N As DateTime = Now
For i As Object = 1 To 10000000
    Test = i
Next
MsgBox((Now - N).TotalMilliseconds.ToString)

Результаты: 2015 мс., 2125 мс., 2046 мс.


VB 2008 .Net тест 2 (заполнение массива типа Object длиной 10 млн. элементов):

Код:
Dim Test(9999999) As Object
Dim N As DateTime = Now
For i As Object = 0 To 9999999
    Test(CInt(i)) = i
Next
MsgBox((Now - N).TotalMilliseconds.ToString)

Результаты: 4750 мс., 4531 мс., 4921 мс.


VB 2008 .Net тест 3 (присвоение значения переменной типа Integer 100 млн. раз):

Код:
Dim Test As Integer = 0
Dim N As DateTime = Now
For i As Integer = 1 To 100000000
    Test = i
Next
MsgBox((Now - N).TotalMilliseconds.ToString)

Результаты: 109 мс., 109 мс., 109 мс.


VB 2008 .Net тест 4 (заполнение массива типа Integer длиной 10 млн. элементов):

Код:
Dim Test(9999999) As Integer
Dim N As DateTime = Now
For i As Integer = 0 To 9999999
    Test(i) = i
Next
MsgBox((Now - N).TotalMilliseconds.ToString)

Результаты: 62 мс., 62 мс., 46 мс.

Получается, Autoit проигрывает в скорости:
при использовании в VB переменных типа Object примерно в 3,5 раза,
при использовании в VB переменной и массива типа Object примерно в 6 раз,
при использовании в VB переменных типа Integer примерно в 650 раз,
при использовании в VB переменной и массива типа Integer примерно в 450 раз.
 

DarWiM

Продвинутый
Сообщения
527
Репутация
90
OffTopic:
Но всё-равно :IL_AutoIt_1:
 

madmasles

Модератор
Глобальный модератор
Сообщения
7,790
Репутация
2,322
Ketoz,
Предупреждение За нарушение правил форума (пункт В.11):
Любые отрывки AutoIt кода необходимо заключать в тег [autoit]
autoit.gif
(подробнее), а обычный код соответственно в тег [code]
code.gif
(подробнее). Также большие выдержки текста помещайте под тег [spoiler]
spoiler.gif
(подробнее), там где это поддерживается естественно. Как в случае с названием темы, также короткое и эргономичное сообщение привлекает больше внимания, и шансы на получение конкретного ответа увеличиваются.


С уважением, ваш Модератор.
 

Ganibal95

GreenBytes
Сообщения
877
Репутация
240
Примерная скорость присваивания переменной на вашем железе!
Код:
$N = TimerInit()
$T = TimerDiff($N)
$N = TimerInit()
$Test = 0
$T = $T - TimerDiff($N)
ConsoleWrite($T&@CR)


У каждого железа свои параметры, и свои цифры...
у меня такие получились:
~0.0019555558038801
 

joiner

Модератор
Локальный модератор
Сообщения
3,556
Репутация
628
Ketoz [?]
Получается, Autoit проигрывает в скорости:
мотив этих сравнений - презрительное отношение к AutoIT.
другого смысла создания темы - "писькомера" я не вижу
 
Автор
K

Ketoz

Новичок
Сообщения
4
Репутация
3
Примерная скорость присваивания переменной на вашем железе!

Странный тест, но все равно напишу. У меня получается разброс от 0.00167619068904009 до 0.00279365114840015. По-моему, сравнивать скорость работы кода можно только за достаточно большие промежутки времени.

мотив этих сравнений - презрительное отношение к AutoIT

Нет, на самом деле я хотел показать что для каждой задачи нужно применять свои инструменты. Подозреваю, об этом многие не задумываются. Как видим, автоит относительно медленный, и для быстрых вычислений не подходит, но зато автоит сильно заточен на работу с окнами, к нему не требуются дополнительные установленные на компьютере библиотеки, как например платформа .Net Framework у VB, без которой он работать не будет. А VB не подойдет для написания какого-нибудь кода с ассемблерными вставками, кому это нужно, его можно писать в C, С++ и т.д. Еще момент - на мой взгляд, намного удобнее писать код в среде разработки VB 2008 (если все хорошо настроить), нежели в Scite и Koda - там автозавершение слов, вставка готовых отрывков кода, подсвечивание ошибок, подсказки, мощная система для отладки, все на русском языке, но весит она сотни мегабайт. Среды разработки 2010 и 2012 у меня работают и компилируют гораздо медленнее чем 2008, хотя особых преимуществ у них нет, поэтому использую 2008. Фактически по устройству и общему стилю VB Net это тот же C#, но с синтаксисом бейсика. Сравнив эти два языка я выбрал VB (например, он "глазастее" :smile:, на мой взгляд его код читать легче), хотя большинству почему то нравится C# ;)
Для себя я в основном пишу программы на VB, но часто использовал автоит для создания простых, библиотеко-независимых приложений, которые можно будет использовать на любых компьютерах с Windows.
 

joiner

Модератор
Локальный модератор
Сообщения
3,556
Репутация
628
Ketoz [?]
Подозреваю, об этом многие не задумываются.
как раз ошибаешься. многие знают. и ты еще не упомянул отсутствие в AutoIT многопоточности. поэтому еще раз говорю - не вижу иного смысла в теме, как уже написал выше.
 

gora

Знающий
Сообщения
315
Репутация
19
Ketoz [?]
Autoit тест 1 (присвоение значения переменной 10 млн. раз):
Дабы уменьшить методологическую погрешность, код нужно немного поменять и сравнивать T3, а не T2
Код:
Dim $Test  = 0
Dim $N = TimerInit()
For $i = 1 To 10000000
Next
$T1=TimerDiff($N)
Dim $K = TimerInit()
For $i = 1 To 10000000
    $Test = $i
Next
$T2=TimerDiff($K)
MsgBox(0, "Прошло", 'T1=' & $T1 & @LF & 'T2=' & $T2 & @LF & 'T3=' & $T2-$T1)
 
Автор
K

Ketoz

Новичок
Сообщения
4
Репутация
3
Попробовал замерять время по этой методике, получилось Autoit медленнее:
при использовании в VB переменных типа Object (тест 1 Autoit и тест 1 VB) примерно в 30 раз,
при использовании в VB переменной и массива типа Object (тест 2 Autoit и тест 2 VB) примерно в 9 раз,
при использовании в VB переменных типа Integer (тест 3 Autoit и тест 3 VB) примерно в 1700 раз,
при использовании в VB переменной и массива типа Integer (тест 2 Autoit и тест 4 VB) примерно в 570 раз.

Еще попробовал вызвать из Autoit и VB случайную функцию WinApi по 1 млн. раз. В Autoit вызывал так:
Код:
DllCall("user32.dll", "hwnd", "GetForegroundWindow").

VB здесь был в 40 быстрее.
Но при небольшом количестве вызовов функций маленькая скорость AutoIt вообще не чувствуется :ok:

И добавлю еще, что все языки высокого уровня намного сложнее по сравнению с AutoIt.
 

Yashied

Модератор
Команда форума
Глобальный модератор
Сообщения
5,379
Репутация
2,724
Ketoz сказал(а):
И добавлю еще, что все языки высокого уровня намного сложнее по сравнению с AutoIt.

Чев выше уровень, тем проще язык (с точки зрения пользователя). AutoIt находится где-то между высоким и сверхвысоким уровнем.
 

_ToBe_

Осваивающий
Сообщения
142
Репутация
35
АutoIt - выигрывает по скорости создания готового, работающего скрипта
Но, проигрывает по скорости выполнения
И снова выигрывает по скорости изучения :IL_AutoIt_1:
 

oesoes

xor eax,eax
Сообщения
171
Репутация
9
Интересную тему откопал.

Простите, что поднимаю ее, все таки тред был начат в 12 году, но все же выскажусь... Когда-то я сильно болел ассемблером и гонялся за низким размером компилированных бинарников и за скоростью выполнения. На разработку+отладку более или менее весомых библиотек уходило много времени. Сейчас же, я понимаю, что мое время дороже, чем размер бинарника и для себя я выбрал язык, на котором я мог бы разрабатывать быстро и не тратить много времени на отладку и проверку возвращаемых функциями значений. Я выбрал Delphi. Прекрасный язык, он многому меня научил и станется в моем сердце на вечно. Скорость разработки, прекрасная IDE, интегрированный отладчик и ассемблерные вставки позволили мне разрабатывать очень быстро.

Многие думают, что это Pascal, но они ошибаются. От Паскаля в Дельфах остался разве что синтаксис и типы данных. Даже не смотря на то, что вся контора и коллеги (да и я) вскоре перебрались на не менее удобный C#, я никогда не перестану любить Дельфы и ассемблер, но к чему это я все, спросит читатель? А к тому, что нужно выбирать инструмент, который наиболее подходит для представленных задач. Не нужно забивать гвоздь пассатижами. Время - это очень дорогое удовольствие, знаете ли... То, что я писал на ассемблере за полтора часа, мой коллега писал за 15 минут на С++, в это же время входила и отладка.

Как не трудно догадаться, что мой КПД стремился к нулю! Но зато мои dll'ки весили мало и работали быстро (с точки зрения машины), но реальный пользователь никогда не считает такты! Ему просто насрать (простите за выражение), на чем я написал ту или иную функцию. Он не увидит и не почувствует, что софт работает быстрее или медленнее на нескольно процессорных тактов или число кеш-промахов. Я хочу сказать, что человеку важно, чтобы софт выполнял свою задачу правильно. Скорость конечно имеет место быть, но современное железо компенсирует эту проблему.

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

Когда мне показали AutoIT я был очень удивлен. Простой синтаксис, нацеленность на автоматизацию и прочие плюхи покорили мое сердце. Конечно, в этом языке я новичок, но уже кое-что умею и быстро учусь, это мне позволяет сам язык. Чтение чужого кода+справка - лучшее обучение. Конечно это не основной язык и конечно он никогда не заменит ни Delphi, ни даже C#, но черт возьми, я предпочту его всем остальным языкам (ну с которыми я работал и которые понимаю, так как знать ЯП нельзя), если вопрос будет стоять например о разработке ПО автоматизации.

Кто-то скажет: "Я _знаю_ Autoit" или "_Знаю_ C#" и будет не прав. Знать язык нельзя (очень в крайних случаях отдельных индивидов). Почему? Мы делаем ошибки даже в устной речи, не говоря уже о письменной, а уж о ЯП и говорить не стоит. Кто из вас, разрабатывая проект длинной более 1000 строк кода не сделает ошибки? То-то же!

Был на отцовской работе дедулька под ником "Петрович" (не знаю, как его там звали. Мужики по отчеству называли) так вот он мог. Но это просто опыт. Программа компилилась без проблем и даже работала, но не без утечек памяти и не без логических ошибок. Петрович ещё пол дня мог сидеть в SoftICE (мощнейший отладчик режима ядра) и искать бажный вызов прерывания, которое (черт бы её побрал) отжимает память. То есть, хоть Петрович и писал быстро, но получалось, что разрабатывал он медленнее остальных... c'est la vie (

Что-то отошел от темы... Пора заканчивать. И вот ещё, что хотел сказать: скорость языка никогда не измеряется в циклических проходах. Для этого есть профилировщики (для автоита я не знаю, есть или нет...). Измерять способом, каким измеряет TC просто неправильно. СISC процессор в один момент времени может выполнять только ОДНУ инструкцию. В случае многоядерных процессоров (например 4) - 4 инструкции, но вычислительный конвейер отдает ядру (ядрам) инструкции по очереди. Невозможно предугадать, когда с конвейера пройдет та или иная инструкция в ядро, всегда по разному. То есть, сейчас инструкция выполнилась за 3 такта например, а на следующий проход выполнится за 2 или 5 тактов! Даже профилировщик не может дать точного значения скорости выполнения, он отдает среднее. Что-то заговорился.
 

C2H5OH

AutoIT Гуру
Сообщения
1,473
Репутация
333
oesoes,

мысль как-то не закончена. Вывод где? Финал, так сказать.
 

oesoes

xor eax,eax
Сообщения
171
Репутация
9
C2H5OH сказал(а):
oesoes,

мысль как-то не закончена. Вывод где? Финал, так сказать.

Финал сей басни такова, что: 1 - так не измеряют скорость выполнения и 2 - не стоит гоняться за быстротой, там где она не нужна. Нет, если вы пишите драйверы для графических плат, то конечно или ядро ос, допустим... Все это имхо, конечно. Не смею никому ничего навязывать.
 

joiner

Модератор
Локальный модератор
Сообщения
3,556
Репутация
628
как я это вижу, с непрофессиональной высоты программирования ( :smile: ), единичные измерения не делают эффективной всю программу, в итоге как бывает, софт, написанный на "быстром языке" весьма "тупит". почему? потому что там не только одиночные вызовы функций из библиотек , и не только создание массивов и не только....ну и так далее, но все это вместе. а все это вместе есть, что то типа, общего алгоритма работы программы.
пусть будет копирование данных. копирование при первом запуске дольше, чем если запустить повторное копирование файлов. настолько дольше, что начинаешь потихоньку материться. а повторно копируешь - все гуд. быстрее раза в три. и тут autoit не уступает по скорости кому - нибудь еще. (разница во времени до 10 секунд не актуальна).но даже самая "быстрая" скорость скоро будет казаться "медленной". привыкаем :smile:
мне приходится работать по сети в 1С. версия программы обновляется. но "затупы" программы все там же..в чем проблема? в самой программе или в конфигурации? обычному пользователю как то все равно. ему просто нужно, чтобы при нажатии кнопки выдало результат, а не зависание.
так что, я могу сделать вывод такой - даже работая относительно "медленными" инструментами, можно написать довольно быстрый софт. главное - продумать под конкретные цели.
можно гордиться как быстро VB складывает 1+1 и при этом в целом написать отвратный, зависающий, глючный софт.
я не питаю иллюзий насчет autoit, но его зачастую более чем достаточно для написания софта учета на работе, к примеру. тут тебе и живой поиск и работа с сайтами и так далее. я реализовал пару - тройку идей по учету материала и в фирме, где я работаю. то же самое есть в 1С, но я сделал отдельные модули для работы на участках производства. и это оказалось весьма востребованным. и никто не сказал, что что-то там в моем софте медленно работает
 

sims

Осваивающий
Сообщения
184
Репутация
24
joiner [?]
бывает, софт, написанный на "быстром языке" весьма "тупит". почему?
Потому что написан индусским быдлокодером. Для тех кто не знает о чем я, читайте. http://lurkmore.to/Индусский_код
Если код написан профессионально, ничего тупить не будет.

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

пусть будет копирование данных. копирование при первом запуске дольше, чем если запустить повторное копирование файлов. настолько дольше, что начинаешь потихоньку материться. а повторно копируешь - все гуд.
Не путайте теплое с мягким! При копировании имеет значение не только то, на чем написан софт, но и скорость чтения/записи винта, фрагментация и другие параметры. При повторном копировании процесс идет быстрее потому что данные кешированны в памяти и нет необходимости их повторного чтения с винта.
Более того, этот пример некорректный, ведь копирует не код программы, а API функция винды и не важно на чем написана прога, т. к. копирует винда.
Пример в первом сообщении темы более корректный, т. к. он показывает скорость работы кода, а не скорость винта.


Теперь по теме. Раз уж сравнивали тут разные ЯП, решил еще и PB проверить. PureBasic обошел VB чего и стоило ожидать, ведь нативный код работает быстрее управляемого. PB выполнил цикл за 16 мс., а VB (переменные Integer), за 32 мс.
 

joiner

Модератор
Локальный модератор
Сообщения
3,556
Репутация
628
sims [?]
Не путайте теплое с мягким
как раз без путаницы. я использовал обычный пример. к файловой система обращаются все.
я привел этот пример как это видит обычный пользователь. не скорость работы в памяти, а взаимодействие со всем железом.
почитал ссылки. хм..почитал , сравнил. наверное я попадаю под эти определения :smile:
в силу своей неучености..смешно.
OffTopic:
Но, лукоморье само страдает некоторыми упомянутыми недостатками. такие сайты сродни быдлосайтам. это мое, сугубо личное мнение, которое сложилось задолго до этого поста
 

inververs

AutoIT Гуру
Сообщения
2,135
Репутация
465
AutoIt проигрывает там, где требуется обсчет больших данных, но выигрывает в скорости разработки. Если делать сложную функцию для шифрования, кодирования, анализа простых данных, и важна скорость, то конечно, лучше подыскать инструмент побыстрее.
 

AZJIO

Меценат
Меценат
Сообщения
2,874
Репутация
1,194
Так ведь никто не запрещает внешнюю DLL подключить. Пожалуйста пиши на Си или на FreeBasic. Только пока что те кто хвалится обычно ничего не умеют как только хвалится, написать три строчки цикл и сравнить, показывая якобы свою крутость и знания. Выложи софт сначала, который ты написал на Си или ещё на чём нибудь, тогда поймёшь цену этой скорости. Да и вообще люди не пишут с нуля код, они всё равно рано или поздно поймут, что легче использовать готовую библиотеку, несмотря на то что она чем то не нравится, синтаксисом или медлительностью, чем пол-жизни изобретать велосипед. На эти библиотеки потрачено время целых коллективов программистов.
Сейчас вот пробую Python, в любом случае он сложнее. Не смотря на то, что уже есть понятия о программировании, Python не даётся так легко как Autoit. Справка на Autoit в сравнении с другими просто совершенство. То есть я 2 месяцв изучаю, но GUI у меня есть только в виде примеров. Вчера написал свой первый скрипт на Python по парсингу листингов и сохранение в отдельные файлы. В Autoit у меня в первые же дни был написан первый GUI, который я в течении месяцев усложнял вкладками и новыми функциональностями. А в Си так вообще был дохлый номер. Так что ваш выбор, складывать циферки в терминале/консоли или писать софт.
 
Верх