[Новая функция] Концепция развития AUTOIT

Я предлагаю немного изменить концепцию развития AUTOIT...
Эта мысль возникла при изучении библиотеки WinAPIEx, которую предложил Yashied...
Большинство стандартных функций AUTOIT реализовано с помощью WinAPI...
Почему бы не вынести из AUTOIT3.EXE все стандартные функции в UDF-библиотеки?
Оставить только команды и функции, которые реализуют построение структуры скрипта...
Думаю, интерпретатор AUTOIT стал бы компактнее, а пользователи подключали бы только те библиотеки, которыми они собираются пользоваться...
Преимущества: меньший объем скомпилированных скриптов, небольшой объем обновлений AUTOIT, в основном, обновление UDF (текстовых файлов), а не интерпретатора...
Ну, в общем, надеюсь, идея понятна...

Я потдерживаю snoitaleR, потому что когда обновляют AutoIT многое режут, столкнулся когда необходимо было производить одновременное чтение\запись из txt\ini файла, а теперь в AutoIT этот баг закрыли, хотя я считаю что это даже не баг был, а разработчики решили усложнить жизнь кодеру :-X

snoitaleR [?]

Почему бы не вынести из AUTOIT3.EXE все стандартные функции в UDF-библиотеки?

Нажмите, чтобы раскрыть...

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

Преимущества: меньший объем скомпилированных скриптов

Нажмите, чтобы раскрыть...

Разработчиков это особо не беспокоит, на сегодня, программы с весом в 0.5 мегабайт - это ничто, раньше боролись за каждый байт, сегодня это кажется прошло (для большинства по крайней мере).

На работе на меня смотрят с подозрением когда я даю скомпилированный скрипт в 10 строчек и весом 300кб)

bulldog5293 сказал(а):

...разработчики решили усложнить жизнь кодеру.

Нажмите, чтобы раскрыть...

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

ak40u сказал(а):

На работе на меня смотрят с подозрением когда я даю скомпилированный скрипт в 10 строчек и весом 300кб.

Нажмите, чтобы раскрыть...

Строчка строчке рознь. Можно и на С# замутить скрипт в 10 строк размером в несколько мегабайт. Для AutoIt, 250-300 КБ - это минимальный размер исполняемого файла. Дальнейшее увеличение веса идет пропорционально исходному коду. Если разработчики напишут полноценный компилятор (заветная мечта Valik'а), то будет и минимальный объем, и соответствующая скорость и т.д., и т.п. Но при этом мы потеряем такие замечательные возможности, как Execute(), Assign() и многое другое. И самое главное - важно не то, сколько весит исполняемый файл, а то, сколько он "съедает" памяти. А здесь все не так уж и плохо...

Так что 30 КБ или 300 КБ в наш век не особо принципиально, и это больше предрассудки, нежели реальная проблема (IMHO). Если уж так важен вес исполняемого файла, то используйте C# + API, и будет вам счастье. Только вот на AutoIt, я могу написать некоторые вещи в 10, а то и в 100 раз быстрее и надежнее, чем на том же C# (один GUICreate() чего стоит). Вообщем, каждый решает сам...

Yashied [?]

важно не то, сколько весит исполняемый файл, а то, сколько он "съедает" памяти

Нажмите, чтобы раскрыть...

Памяти он сразу берет лишку, я постоянно использую функцию _WinAPI_EmptyWorkingSet() из Вашей замечательной библиотеки WinAPIEx.au3 и потребляемая память уменьшается в разы. :IL_AutoIt_1:

На самом деле, физически выделенную память уменьшить таким вот волшебным образом нельзя. Это из ряда фантастики. _WinAPI_EmptyWorkingSet() тупо свопит максимально возможное количество страниц выделенной приложением памяти в файл подкачки. Вот и все. Другое дело, что большая часть из этой памяти AutoIt'у в ходе выполнения скрипта уже не понадобиться, поэтому первоначальный размер не будет достигнут после вызова этой функции. Что есть очень и очень хорошо. Но в любом случае, не стоит злоупотреблять _WinAPI_EmptyWorkingSet(), т.к. постоянный свопинг не лучшим образом скажется на производительности, особенно на компьютерах с не очень быстрыми HDD. Вы и сами можете в этом убедиться на слабеньких ноутбуках. При сворачивании окон, так же происходит "сброс" памяти. Что объясняет долгое время разворачивания некоторых окон в ресурсоемких приложениях, например в Adobe Photoshop (кстати, в 7-ке с этим немного лучше обстоит дело). Вот несколько рекомендаций по использованию _WinAPI_EmptyWorkingSet():

• Используйте функцию _WinAPI_EmptyWorkingSet() только один раз при старте скрипта (лучше в самом начале кода и до вызова GUICreate()).
• Если программа является резидентной и предусматривает открытие/закрытие каких-либо диалоговых окон, то используйте эту функцию также после вызова GUIDelete().
• При появлении ощутимых задержек при выводе всплывающих окон (например Pop-ups.au3), откажитесь от вызова _WinAPI_EmptyWorkingSet() после скрытия/удаления таких окон.
• Ни в коем случае не вызывайте переодически _WinAPI_EmptyWorkingSet() внутри каких-либо циклов.
• и т.д.

Полностью разделяю мнение Yashied`а! :beer:

Yashied
Большое спасибо за консультацию!
Можно уточнить. У меня постоянно в работе висит скрипт, который периодически выполняет нужные мне действия. Такое использование функции _WinAPI_EmptyWorkingSet() корректное?

madmasles

Все зависит от "выполняемых действий", но в 99% случаев корректно будет так:



Сами посудите, зачем каждый час свопить память? Если программа написана корректно и нет утечек памяти, то теоретически, объем выделенной памяти должен держаться на одном уровне. Если через час это число возросло, а через два часа возросло еще больше, то на лицо утечка памяти и нужно срочно лезть в код. А вызвав _WinAPI_EmptyWorkingSet() в начале кода, мы избавляемся от той самой "лишки", которую AutoIt так бессовестно выделяет под себя. Хотя, возможно для чего-то она ему и нужна...

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