Ok, so in getting all excited about possible Multi-Threading in Xojo 2020rX, I realize that it’s “nothing new under the sun”, just using console apps in another way.
Ok, so I’m curious if using console apps would speed things up for my software. I would need to be able to access shared memory for this to work, and I understand that I might need to use an MBS plugin to do this, no problem, I have the suite already.
My program has 3 TCP sockets sending and receiving data. I would like to figure out if having the send/receive functions on separate threads in Xojo would speed things up.
Each thread needs a send and receive buffer, accessible from the main GUI app as well as all the other threads. Probably an event for the event to tell the gui that there’s new data. The thread can just keep looking at the buffer and if it has data, pop it off the queue and send it.
Anyone like to help me figure out how the shared memory would be implemented? I didn’t see an example on the MBS site (doesn’t mean there isn’t one, just means I didn’t find it)
I’d use queue-style buffers typically (FILO stacks/arrays).
First the question is what multi threading would help you.
If you use TCP Sockets to process incoming requests, it will not help unless you can spawn out processing of something to the console apps.
e.g. if you run a service, where a GUI app sends JSON requests containing jobs for image processing, you may run each job with a worker. The GUI app sends input/output file paths and what to do, you pass it to one of the workers and pass result back. As processing is then done in the worker, you can run 10 in parallel and get more jobs done in a given time range.
Maybe I wasn’t clear. What I do in .NET is have separate tasks (threads) where each socket sends and receives data to buffers that the main GUI thread can manipulate. By having these functions on separate threads, data can come and go from each socket continuously without any other socket slowing down or the GUI slowing things down. Works very fast. Trying to see if that would be feasible in Xojo.
So, in Xojo, can I create separate console apps that run in their own threads that do nothing but wait until there’s a message on an outgoing buffer and pop that message from the queue, send that message, and also wait until a message comes in from the socket and when it does, push it onto an incoming queue?
The other threads and main GUI need access to these queues.
The other question is whether or not the Xojo TCPSockets themselves are slowing things down more than not having them on another thread is…
I Xojo sockets are already asynch so threads wont buy you a lot extra
In Xojo a worker is not a separate THREAD (that implies its in the same process) but actually completely separate CONSOLE APPLICATIONS - so no they cant share memory directly unless ou opt to use some shared memory mechanism that is NOT part of Xojo
putting them on a thread isnt going to make them any faster since Xojo uses cooperative scheduling between threads
but as separate processes the OS takes over scheduling and that CAN be fully preemptive or even run on an entirely different core at the exact same time
Getting stuck on semantics. Threads in other languages spawn out to other threads and cores as needed, so that’s why I keep using the word “thread”. I understand that in Xojo it’s something different, but let’s not get stuck on that.
Are both of you saying that having separate worker apps sending and receiving socket data will not speed things up? If not, then no need to figure out how to make that work!
Yes. For an app with ServerSocket taking requests, it may not help to use threads or workers.
Unless you do some work and can put that work in a thread or worker.
Workers, or separate helper apps, may help as they are completely separate apps not throttled by Xojo’s cooperative thread scheduling
Xojo’s socket are already asynchronous though so threads may NOT be useful in any event
Xojo threads are unlikely to help as much as you need / want because they are scheduled cooperatively and NOT run on separate cores like so many other languages do
I think all here are talking about different things. To really get a propper answer more information is needed:
1 What is the amount of data you are sending/receiving?
2 The data has to be processed before sending or after receiving?
3 If yes, is a loto of work?
4 Do you already have a bottle neck?
As ancient history, 12 years ago I had to make an APP that worked like a spider, download 10,000 pages, parse the HTML get like 100 values from there and store in a database. After DAYS with “real basic”, it was capable of downloading in like 12+ hours.
Did it in VB.Net, cookies, session management, compression, real multithreading, etc, already built in. tookme a couple o hours and I got top speed with 10 real threads (limited by the server), all the data downloaded and parsed in 20 minutes
Not sure. Can that be measured in wireshsark or something? Let me know and I’ll find out.
Yes, but only simple filtering. Compare a few bytes in the message.
Simple filtering on each packet. In some cases a lot more, but in those cases speed doesn’t matter.
Oh yes. It could be a LOT faster. Comparing direct hardware to software communication vs going through Xojo where it’s simply receiving and forwarding packets, it’s much slower via Xojo, even with just simple filtering.
However, you bring up a good point. I should make a test version of my software with any additional processing and GUI updates removed and do some tests to make certain what actual function is slowing things down.
Never had to think about it in .NET - it was always plenty fast!
However, it doesn’t seem to be appearing on debug. I checked “Profile Code” in the Project menu, and while it creates a profile.txt when I build and run the app, it’s not particularly readable (I know, I can parse it) but it says in the user guide that there should be a Profiles entry in the Navigator. I don’t see it, whether I run the app in the IDE or build and run it outside.
To be clear, it does create profile.txt when I build the app and run it outside the IDE. I just don’t see this Profile item added to the navigator when I run the app from the IDE. And I am quitting the app using the quit function in the app.
Maybe there’s an issue with the way my app closes?
