I've tryed to profile one of my application using Qt.
The results I found seemed to show that Qt is a big Thread user. It seems to create and destroy threads a lot. Which is the peak of its memory consumption. Is it true ?
So I've tryed to do some research on "how to optimize a Qt application" but, well I hadn't found anything relevant for now.
So I was wondering if there is any "general way" of programming with Qt that could be optimized. Shall I use the threads in a specific manner ? Can I do anything except respecting C++ standards, -pedantic options in compiler, and so one ?
Generally speaking, if you create and destroy threads a lot, then that's probably not a very good design. Assuming your threads do the same (or similar) things, then having a fixed "pool" of threads that run for as long as it takes and then get put back in the pool when your current code destroys the thread.
Or, let the thread run forever, and feed it data through some suitable IPC.
I would also say that unless you are doing something very special, if something takes less than about a quarter of a second to do, then you shouldn't create a thread to do that. That's not a fixed rule.
Threads as such don't use that much memory, but the stack of each thread may use quite a bit of memory.
If you're creating and destroying QThreads a lot, consider using a QThreadPool or QtConcurrent. These will hold threads in reserve and serve them on demand.
If you're not creating and destroying threads a lot, then your problem is elsewhere.
Related
Context:
I am working on an application that needs fast access to large files, so I use memory-mapping. Reading and writing becomes a simple memcpy in consequence. I am now trying to add the ability to abort any reads or writes in progress.
The first thing that came to mind (since I don't know about any interruptable memcpy function) was to periodically memcpy a few KB and check if the operation should be aborted. This should ensure a near-instantanious abortion, if the read is reasonably fast.
If it isn't however the application shouldn't take ages to abort, so my second idea was using multithreading. The memcpy happens in its own thread, and a controlling thread uses WaitForMultipleObjects on an event that signals abortion, and the memcpy-thread. It would then kill the memcpy-thread, if the abortion-event was signaled. However, the documentation on TerminateThread states that one should be absolutely sure that one does not leave the system in a bad state by not releasing ressource for instance.
Question:
Does a memcpy do anything that would make it unsafe to kill it when copying mapped memory? Is it safe to do so? Is it implementation dependant (using different operating systems/architectures than Windows x86-64)?
I do realize that using the second approach may be complete overkill, since no 1KB read/write is every going to take that long realistically, but I just want to be safe.
If at all possible you should choose a different design, TerminateThread should not be thought of as a normal function, it is more for debugging/power tools.
I would recommend that you create a wrapper around memcpy that copies in chunks. The chunk size is really up to you, depends on your responsiveness requirements. 1 MiB is probably a good starting point.
If you absolutely want to kill threads you have to take a couple of things into account:
You obviously don't know anything about how memcpy works internally nor how much it copied so you have to assume that the whole range is undefined when you abort.
Terminating a thread will leak memory on some versions of Windows. There are workarounds for that.
Don't hold any locks in the thread.
I have a question concerning long calculations:
While executing some tasks of my GUI long calculations might be done. This is not a problem, it just takes a while – everything works fine (at least the results are fine).
What bothers me is that after a certain time my GUI doesn't seem to respond: For example my ProcessBar that is shown during calculations will not be displayed and in the title bar of my GUI the text “keine Rückmeldung” is added (which means something like busy, crashed, etc - sorry I don't know the correct translation which makes it hard for me to find anything in the internet about that issue).
Is there a possibility to stop that behavior?
Thank you.
You should outsource your expensive, long-lasting calculations from the GUI-Thread to a worker thread to prevent your GUI from freezing.
Qt-Documentation: Threading Basics
Good explanation of QThread-usage I found useful: How To Really, Truly Use QThreads
The GUI itself cannot be changed from a worker thread. You have to notify your main-thread about a data-change and update your GUI from there.
You have two options. The more efficient one is to put your calculations into another thread (or multiple threads, there are very few single core CPUs in modern PCs). JSilver's answer has a few links for you.
However, with threads come multitude of threading related things you must learn and take into account. There's a lot of potential for subtle bugs, if you don't know what you're doing. So I would recommend alternative approach as first step, single-threaded. As a bonus, it'll make moving to multi-threaded solution much easier later.
Create a plain sublclass of QObject. Into this QObject, put the state of your calculation as member variables.
Write a slot method into above class, which does a small piece of the calculation, then returns. It should do it's thing at most around 50 ms for good user experience. You can just use a fixed number of iterations in your loop, or use QElapsedTimer to measure time, or whatever. And then, when called again, the method should continue the calculation again for another 50ms. When calculation completes, the method can for example emit a signal with the results.
Add a QTimer with interval 0. Connect the timeout to the slot method described above. Interval 0 here effectively means, Qt will call the method as often as it can. You want this, because you want the calculation to finish as quickly as possible of course. However, since the method returns very soon, then Qt can do other stuff (update GUI etc), before calling your method again.
Once this works, in single thread, you can then learn to do Qt threading and move the worker object to live in another thread, for potentially increased performance. Also then you will have a single-threaded baseline version to compare to, in case you run into threading problems.
I'm making a desktop programming game with C++11, Qt 5.6 (soon 5.7 once V-Play supports it), and QML. The user will be able to write arbitrary code to solve puzzles; however, the code should be entirely sandboxed and not cause problems with the rest of the application.
So I instantiate a scripting engine whose environment I completely control and run the player's code through that. I won't say what scripting engine because I don't want a solution to rely on the engine (plus, I may support multiple languages). When the player hits "Submit", I run the script asynchronously, so that the rest of the game is still responsive.
But here's my problem: What happens if the player's code takes a long time to run? Or worse, what if it's an infinite loop? The player will be making mistakes as they learn, so "they shouldn't do that" is not a valid answer here.
So I'll just let the player terminate their code at will, fine. But how can I do that without risking undefined behavior, memory leaks, a crash, or other things that may negatively affect the game?
Of relevance is the following:
The solution should be multi-platform.
The solution should not depend on what scripting engine I'm using.
I'm not passing around data between threads, so I don't need to worry about data races.
The QFutures that QtConcurrent::run returns do not support QFuture::cancel.
You cannot rely on being able to safely kill C/C++ threads. Any thread which is doing any meaningful work will need to acquire locks and/or allocate memory to do its work; killing the thread will potentially leave some locks permanently held, or memory never deallocated. Depending on the details, this is likely to cause your application to run out of memory after many scripts are killed, or cause it to lock up entirely if the main thread tries to acquire locks held by a killed interpreter thread.
If you need to be able to interrupt running scripts, you will need to choose scripting engines which specifically allow for this. Not all will; you will need to avoid the ones that don't support it.
I have a project and I want to convert it to multi-threaded application. What are the things that can be done to make it a multi threaded application
List out things to be done to convert into multithreaded application
e.g mutex lock on shared variables.
I was not able to find a question which list all those under single hood.
project is in C
Single threaded application need not be concerned about being thread safe.
This issue arises when you have multiple threads which are trying to access a commonly shared resource. At that time, you must be concerned.
So, no need to worry.
EDIT (after question been edited ) :
You need to go through the following links.
Single threaded to multithreaded application
Single threaded to multithreaded application - What we need to consider ?
Advice - Single threaded to multithreaded application
Also a good advice for converting single to multithreaded application.Check out.
Single threaded -> Multithreaded application :: Good advice.
The big issue is that, in general, when designing your application it is very difficult to choose single thread and then later on add multi-threading. The choice is fundamental to the design idioms you are going to strive towards. Here's a brief but poor guide of some of the things you should be paying attention towards and how to modify your code (note, none of these are set in stone, there's always a way around):
Remove all mutable global variables. I'd say this goes for single threaded applications too but that's just me.
Add "const" to as many variables as you can as a first pass to decide where there are state changes and take notes from the compilation errors. This is not to say "turn all your variables to const." It is just s simple hack to figure out where your problem areas are going to be.
For those items which are mutable and which will be shared (that is, you can't leave them as const without compilation warnings) put locks around them. Each lock should be logged.
Next, introduce your threads. You're probably about to suffer a lot of deadlocks, livelocks, race conditions, and what not as your single threaded application made assumptions about the way and order your application would run.
Start by paring away unneeded locks. That is, look to the mutable state which isn't shared amongst your threads. Those locks are superfluous and need to go.
Next, study your code. At this point, determining where your threaded issues are is more art than science. Although, there are decent principals about how to go about this, that's about all I can say.
If that sounds like too much effort, it's time to look towards the Actor model for concurrency. This would be akin to creating several different applications which call one another through a message passing scheme. I find that Actors are not only intuitive but also massively friendly to determining where and how you might encounter threading issues. When setting up Actors, it's almost impossible not to think about all the "what ifs."
Personally, when dealing with a single threaded to multi threaded conversion, I do as little as possible to meet project goals. It's just safer.
This depends very heavily on exactly how you intend to use threads. What does your program do? Where do you want to use threads? What will those threads be doing?
You will need to figure out what resources these threads will be sharing, and apply appropriate locking. Since you're starting with a single-threaded application, it's a good idea to minimize the shared resources to make porting easier. For example, if you have a single GUI thread right now, and need to do some complex computations in multiple threads, spawn those threads, but don't have them directly touch any data for the GUI - instead, send a asynchronous message to the GUI thread (how you do this depends on the OS and GUI library) and have it handle any changes to GUI-thread data in a serialized fashion on the GUI thread itself.
As general advice, don't simply add threads willy-nilly. You should know exactly which variables and data structures are shared between threads, where they are accessed, and why. And you should be keeping said sharing to the minimum.
Without a much more detailed description of your application, it's nearly impossible to give you a complete answer.
It will be a good idea to give some insight in your understanding of threading aswell.
However, the most important is that each time a global variable is accessed or a pointer is used, there's a good chance you'll need to do that inside of a mutex.
This wikipedia page should be a good start : http://en.wikipedia.org/wiki/Thread_safety
In Cocoa, is NSThread faster than pthread? is are any performance gain? is it negligible to ignore?
I have no data to back this up, but I'm going to go out on a limb and say "they're equivalent". NSThread is almost certainly wrapper around pthread (is there really any other way to create a system thread?), so any overhead of using NSThread versus pthread would be that associated with creating a new object and then destroying it. Once the thread itself starts, it should be pretty much identical in terms of performance.
I think the real question here is: "Why do you need to know?" Have you come up against some situation where spawning NSThreads seems to be detrimental to your performance? (I could see this being an issue if you're spawning hundreds of threads, but in that case, the hundreds of threads are most likely your problem, and not the NSThread objects)
Unless you have proof that the creation of an NSThread object is a bottleneck in your application, I would definitely go with the "negligible to ignore" option.
pthreads actually have slightly less overhead, but I can't imagine it will make any difference in practice. NSThread uses pthreads underneath. The actual execution speed of the code in your thread will be the same for both.
Under iPhone SDK, NSThread uses pthread as an actual thread. Frankly, they're equivalent.
However, we can access "deep" settings via pthread APIs if we use pthread API. For example, scheduling way, stack size, detached or not, etc. These API are hidden by NSThread capsule.
Therefore, under some conditions, pthreads win.
I would also guess that any "overhead" or "instantiation difference" you pay as an extra for NSThread, would be evened by the extra cycles and calls you will eventually need to perform, to configure your pthread correctly, using pthread APIs.
I believe the NSThread is nothing but convenience wrapper that saves some coding in Cocoa/Cocoa-touch applications that want to be multithreaded.