Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ Scripting resource usage
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Poromenos
Greece (1,037 posts) Bio
|
| Date
| Sat 24 May 2003 01:37 PM (UTC) |
| Message
| I am a bit worried about the resource usage of scripting. Does every plugin start its own instance of the script debugger? And, what's more, whenever i send a trigger/alias/timer/whatever to "Script", does MC create a new scripting engine instance to run it in? If so, "Send to Script" shouldn't be used lightly, am I correct?
If it was zMud, I wouldn't worry, because that's bloated as hell anyway :p |
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it! | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Sat 24 May 2003 08:49 PM (UTC) |
| Message
| It's not as bad as that.
For a start, the script engines are DLLs which by their nature are shared resources for the whole PC. If you are using VBscript or JScript they are probably already loaded, for web pages.
If not, then you will have one instance of the DLL loaded, per language used, no matter how many worlds you have open.
Then, per world, the script engine will have an "engine space" created for the main world, and each plugin (each plugin that uses scripting, that is).
The "send to script" you mentioned, uses the main world script space, so that is no more inefficient than just typing in script commands into the command window.
The script engine script spaces are probably reasonably efficient (I can't say for sure as I didn't write them) but I can't imagine why script writers would use more memory than they needed to.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Reply #2 on Sat 24 May 2003 09:04 PM (UTC) |
| Message
| Yes.. I am a bit curious about how this works exactly myself. It for instance occured to me with a bit of searching around that you can install wxWindows and wxPython. This gives you access to the Frame object that provides the basic building block for all windows applications. So the idea is roughly:
1. Include the wxPython module.
2. Create a frame.
3. Create a button to put on the frame.
4. Initialize the frame (must be done directly since you can't obviously 'run' a main loop).
5. Show the new window.
6. Click the button.
The last one would 'normally' cause a callback to execute like:
On_MyButton(...){
world.note "You pressed my button!"
}
However, this will only work if the script remains 'active' in the engine and it is thus possible for the callback to be recieved by the script. The fact that global variables remain intact from one script call to another tends to imply that the engine does continue to stay in a wait state for external events and that this 'should' work, but I really don't have a clue if I am right. This is especially confusing in the cases Poromenus points out, where you employ 'Send to Script' or plugins. I assume that the answer is yes, in that specific case a new engine instance is called each time such a request is made, as well as with each seperate plugin you load (though only once per plugin) and that you probably can't use 'Send to Script' to directly call subroutines in the main script file any more than you could do so from a plugin.
However, I suspect that since the script engines are designed to provide, for those using such servers, server side scripting that might process requests from hundreds of users with minimum overhead, that unless you used 'Send to script' for every single trigger and you had 10,000 of them all go off at the same time... | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Sat 24 May 2003 09:38 PM (UTC) |
| Message
| The script engine is not in a "wait state" as you describe it, or not what I would call a "wait state". It is simply initialised.
It only gets events when MUSHclient chooses to hand them to it, which is at well-defined points, such as when a trigger fires, or you type something into the command-line. Then that is passed to the script engine, which "wakes up" so-to-speak and processes the new call, in the previous context.
Since the "send to script", immediate window, and command-line all share the same script engine space as the triggers, aliases and timers in the main world (but not plugins) then you can in theory interact between them.
For example, you could create a sub in the immediate window, and then call it from "send to script". A trigger could make a sub (using Exec) which could then be used by an alias. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Reply #4 on Sat 24 May 2003 10:00 PM (UTC) |
| Message
| | Hmm. Ok.. Then that still begs the question of if a secondary process called by the script itself can interact with it. Would a call generated by a seperate objects like the button also wake up the engine and if it did, would it correctly talk to mushclient. For Java, VB and possibly Perl this isn't a major issue, since they can only use script complient objects like databases that are considered 'safe' and by their nature do not persist beyond performing the requested task, but Python has access to things the other two don't allow. A window that was created in it that allowed the calling task to continue running would either hang the client anyway, do to mushclient never seeing the script exit, or be immediately lost due to the engine 'sleeping' when the script returned control to mushclient... Guess I will just have to try it one of these days and see what actually happens. | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
14,377 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top