23 replies to this topic

[Ontosy]

Every time that nozzle a script keeps in memory various copy of autoit.exe.
It is possible to split autoit.exe in a autoit.exe small with the function launch the scripts. au3 and a autoit.dll that it comes recalled from all the autoit.exe launch?
Therefore the memory would be occupied from a great solo autoit.dll and many small autoit.exe instead of being occupied from many autoit.exe.
Excused my English.

[Zedna]

Look at a3x - isn't it solution?

Note: scripts can be compile with .a3x extension. They should be run with AutoIt.exe filename.a3x. The .a3x contains the script itself with all referred #include plus the FileInstall files. This format allow to distribute smaller files as they don't include the AutoIt3.exe in each compile script. You still need to have it accessible on the target machine but just AutoIt3.exe.

[Ontosy]

Look at a3x - isn't it solution?

not why in the RAM memory if run 3 a3x it launch 3 big autoit3.exe.
i would to lanch 3 mini autoit.exe and 1 big autoit.exe.

[Richard Robertson]

I understand what is being asked. Dlls are loaded into memory and are used by every program that needs them. Each executable file gets it's own memory space while a dll is loaded only once. Think of it this way.

3 * full executable(1 MB) = 3 MB
3 * mini executable(.1 MB) + 1 * dll(.9 MB) = 1.2 MB

Does the question make more sense now?

[Ontosy]

Does the question make more sense now?

Yes, i say it

[JSThePatriot]

I can see that is exactly what he wants. What I would recommend is that you make a script that starts the "Big" Executable, and have a few .a3x scripts waiting to be executed, and use the /execute script option. One "Big" Executable can execute more than one script if I am remembering correctly.

The syntax is as follows...

Run(@ScriptFullPath & ' /AutoIt3ExecuteScript ' & $PathOfNextScript)

I haven't actually tried this myself which means it may create a second instance of the AutoIt executable, but as stated before .a3x extension is so you can have multiple scripts, but with one big executable.

JS

[Gene]

I can see that is exactly what he wants. What I would recommend is that you make a script that starts the "Big" Executable, and have a few .a3x scripts waiting to be executed, and use the /execute script option. One "Big" Executable can execute more than one script if I am remembering correctly.

The syntax is as follows...

Run(@ScriptFullPath & ' /AutoIt3ExecuteScript ' & $PathOfNextScript)

I haven't actually tried this myself which means it may create a second instance of the AutoIt executable, but as stated before .a3x extension is so you can have multiple scripts, but with one big executable.

JS

H'mmn, if those .a3x scripts can communicate with each other via the registry or some other method, wouldn't that give some degree of parallism?

The initial script could be minimal, just code to launch the .a3x scripts and then run a While 1/WEnd loop. The other scripts could access each other for simultaneous tasks like say running an I'm busy now clock while a large _arraysort() is running in the background, or do other proccessing giving a discrete(sp?) result.

Gene

Edited by Gene, 29 April 2007 - 05:10 PM.

[JSThePatriot]

H'mmn, if those .a3x scripts can communicate with each other via the registry or some other method, wouldn't that give some degree of parallism?

The initial script could be minimal, just code to launch the .a3x scripts and then run a While 1/WEnd loop. The other scripts could access each other for simultaneous tasks like say running an I'm busy now clock while a large _arraysort() is running in the background, or do other proccessing giving a discrete(sp?) result.

Gene

When you are executing a new script you can use command line parameters to communicate between them. Or create a communication file or use the registry as well.

I hope this helps you on your journey,
JS

[Gene]

When you are executing a new script you can use command line parameters to communicate between them. Or create a communication file or use the registry as well.

I hope this helps you on your journey,
JS

Thanks for the quick response. I was asking a slightly different question. I carefully used the word parallelism instead of multi-threaded proccessing, hoping to avoid a flame. If you can have multiple "modules" working different aspects of one overall task, isn't that a form of multithreading?

Gene

[JSThePatriot]

Thanks for the quick response. I was asking a slightly different question. I carefully used the word parallelism instead of multi-threaded proccessing, hoping to avoid a flame. If you can have multiple "modules" working different aspects of one overall task, isn't that a form of multithreading?

Gene

In a manner. Multi-threading is using one executable with different forks in it to work all together. Using different Modules to work on different problems in procedural way, and making your own synchronization functions is in a way multi-threading, but different.

I hope that answers your question.
JS

[Richard Robertson]

You all are missing Ontosy's question and apparently my explanation as well. Ontosy isn't asking for communication between scripts in any form whatsoever. Ontosy is asking that the bulk of AutoIt be in dll form so that it is only loaded into memory once instead of for every script that needs to be executed.

[JSThePatriot]

You all are missing Ontosy's question and apparently my explanation as well. Ontosy isn't asking for communication between scripts in any form whatsoever. Ontosy is asking that the bulk of AutoIt be in dll form so that it is only loaded into memory once instead of for every script that needs to be executed.

Okay, I understand that, but unfortunately AutoIt isn't going to have a DLL.

JS

[quaizywabbit]

this makes sense to me...

however the current exe is still quite small by todays standards so expect a lot of resistance.........

[Ontosy]

You all are missing Ontosy's question and apparently my explanation as well. Ontosy isn't asking for communication between scripts in any form whatsoever. Ontosy is asking that the bulk of AutoIt be in dll form so that it is only loaded into memory once instead of for every script that needs to be executed.

You are OK

I understand that, but unfortunately AutoIt isn't going to have a DLL.

i have writed this post in "Feature Requests" to suggest

Edited by Ontosy, 29 April 2007 - 06:39 PM.

[Gene]

In a manner. Multi-threading is using one executable with different forks in it to work all together. Using different Modules to work on different problems in procedural way, and making your own synchronization functions is in a way multi-threading, but different.

I hope that answers your question.
JS

Yes, it did, I also already understood the "real" meaning of multi-threading. I am thinking of using a .a3x script for things that can't be covered with a Progress Bar like array sorts. I kept following up because because I keep reading people who want to do multi-threading in spite of Valik's tireless efforts. Maybe they hadn't thought of using .a3x scripts. If any of them run across this thread it will give a whole new direction to explore.

I appreciate your responses.

Gene

[Ontosy]

In order to make this, it would be sufficient to recompile the source in format DLL and to create a small file in order to link it?

Edited by Ontosy, 11 May 2007 - 11:12 AM.

[Ontosy]

Do it is a bad idea?
i'm capable to run 10 autoit.exe instead of 1 autoit.dll

[Richard Robertson]

Yes, Ontosy, I'm afraid that this idea will not pull through. When you receive no new replies for that long a span of time, you'd be better off giving up.

[Raik]

autoit may use dll's as well, right?
why not write a script, witch launches the dll and compile it? or, if possible, call the dll via batch-file with this script as param, to get the dll memory resistant?
just an idea ...