eyez wrote:I will have a look at gbxremote to see if I can speed up the polling of callbacks.
I didn't want to imply that the implementation of GbxRemote.inc.php is necessarily the cause of slowdowns. Usually, this depends more on how this include library is used in an application like Aseco.
I don't know how Aseco is actually implemented but if it serializes the processing of callbacks, then all plugins would have to wait for the currently active plugin; only after the plugin has completed its processing of a callback, the next plugin would get its turn to process that callback.
For example, the /add <tmx-id> command of your RASP plugin downloads a track file over the internet and stores it in the dedicated server's Track directory. Such input and output operations (often just referred to as "I/O") are relatively slow compared to mere computing tasks. While the /add command is processed, all other processing in Aseco would have to wait.
Usually, there are two solutions for this issue: asynchronous I/O and multi-threading. I don't know if either is available with PHP or if Aseco is utilizing it. With Python, both solutions are possible. The idea of multi-threading is to relay tasks to dedicated threads which process these tasks (nearly) in parallel, thus allowing to process the next task despite the current one has not yet been completed.
With asynchronous I/O you would, for instance, start the download of a track file but wouldn't wait for its completion. Instead, you would get a notification when the download finishes. (This is very similar to the callback mechanism used by the dedicated server.) In the meantime, other plugins could get their turn.
Having said that, the performance does not so much depend on the tools you use but more on how you use these tools, i.e. how you structure your implementation.
I haven't studied the code for your python gbx module yet, but will this use the same process, and if so is it any faster?
Like GbxRemote.inc.php, my Python module for GBX offers buffering of received callbacks in a list that an application polls (in class Gbx.AlternativeClient). Additionally, you can register handler procedures which are invoked when particular callbacks are received (in class Gbx.Client). Both methods serialize the processing of callbacks, too. Neither method is necessarily superior to the other one, for reasons I tried to explain above. For example, you could implement a dispatching of tasks to dedicated threads using either of these methods.
I am considering writing a server plugin in python but would only do so if I were to see a noticeable performance gain, especially when retrieving callbacks. I know that python is also a scripting language but have heard it is faster than php, and it would also allow the use of multi-threading which php cannot offer. I wouldnt want to begin a whole new project in python unless I knew there were substantial benefits over php. Any thoughts on this?
I have hardly worked with PHP, thus I cannot really assess its performance in comparison to Python. However, these languages were designed with different focuses. As far as I know, PHP was designed to support the development of web-based applications. In contrast, Python was designed from the start as a multi-purpose scripting language which should support rapid application development with prototyping as well as implementing production-level applications. In my humble opinion, Python is better suited for implementing a server plugin than PHP.
In conclusion, I can't give definite answers to your questions. You have to consider the choices and make your own decision based on what suits you best.