I would like to do some profiling and benchmarking of Qt. The purpose of the profiling and benchmarking is to get the better understanding of Qt, and see what functions take most of the time, where are typical bottlenecks, is it rendering or some event processing, etc.
Can anybody suggest me what application to use for the benchmark? Are there any sample benchmarking applications that exploit Qt GUI? Is there anything like that that comes with the SDK?
The SDK comes with a bunch of examples and demo programs. The demo programs cover all the major aspects of Qt. You could use that to benchmark each of them pretty simply.
Going with larger apps (like KDE, or QtCreator itself maybe) is going to be much harder because of the complexity of the code and amount of non-Qt stuff (for KDE).
valgrind http://valgrind.org/ is a powerful profiler
Related
The QT dev kit comes with some good examples of how to code features via trivial apps, but nothing comes close to showing how to structure a complex program in QT. What, if anything, should be global, etc? Pitfalls in designing your classes that would turn out to need a lot of eventual refactoring?
I'm sure there are plenty of open source KDE apps that would serve nicely, so I guess my question is what't the minimal amount of source code I'd need to download and set up in order to work with, say, Dolphin as a sample app? If the answer is 'all of KDE', then I guess this isn't practical (unless downloading and building all of KDE from source is easy enough to make that practical).
Any suggestions? Personally, I'm looking to build a browser-like app, but much simpler. So for an example to follow, something that handles sockets and multiple tabbed viewports would be nice.
Thanks,
Rob
The main advice regarding Qt itself is I would give is to try to spend as much effort as possible in learning to use Qt's Model View Delegate functionality. It can be a lot of work to wrap your head around, but once you get there, you can do very powerful things with it. Another relatively tricky topic you will want to invest learning resources in is memory management and how Qt facilitates (and doesn't facilitate) it.
One of the most confusing things to me was though that when your model is very complex, you might not want to have your core model class be a Qt model at all. Instead, I nowadays see Qt models as something that primarily provide data to views. If your model is very complex, you might want to use your actual, more complex model as a data source for the Qt model class (an QAbstractItemModel derivative), which in turn attaches to the UI view.
Also, Qt documentation is your friend. Qt is a wide framework and contains LOTS of useful functionality. I love the data structures in their ease of use, for example: QHash, QList, etc.
Project scaffolding features for beginners, for different project types in Qt Creator might indeed be useful. For now, the Qt Examples actually are quite good ones, and contain lots of good practices. You just need to pick and choose what you need.
I have been developing our Qt desktop app family for five years now. Our directory structure is quite unorthodox - the main thing is that we have lib/ under which we have grouped different related functionality in subdirectories. The thinking goes, if something is in lib, it is general-purpose and atomic enough to be used in several of the actual desktop applications in our software family.
Your question seems more general level than Qt. It is difficult to tell if you are looking for a more general level computer science education. Globals in general should be avoided, sure. OTOH, we do have a constants.h and other immutable configuration data that is global-like, since it is needed in many places. This adds state though, so it can have unpredictable consequences if you don't do it carefully.
You could look for directory structures in places like this, though I don't really follow this advice myself. http://hiltmon.com/blog/2013/07/03/a-simple-c-plus-plus-project-structure/
Unless you are planning to contribute directly to KDE, I would advice against learning KDE way of doing things. Not necessarily because they are doing things badly, but because it is a world of its own - the best practice for KDE development might not be the best practice for a stand-alone Qt app. (Disclaimer: I, as a UI developer, don't actually like KDE, so I do not know the project very well - aside from the fact that it indeed seems a bit monolithic to the outsider.)
So I wonder if something like Qupzilla would fit the bill for you? (Found via qt-apps.)
HTH.
I have to port a project from Borland C++ Builder 5.0 under Windows XP to Qt 4.7.1 using g++ under Windows 7/mingw. The libraries and command-line utilities are done, and now I have to tackle the GUI applications, which use Borland VCL.
Can anybody recommend any tools or libraries to make this task easier?
Does anybody have any experience of this?
Edited to add: Well, I took the bull by the horns, and implemented the GUI from scratch. And I have to say, the commentators were right: I can't see any way of using the existing Borland GUI to ease the process.
There are several big differences between VCL and Qt that will make an automatic conversion process quite difficult.
Qt uses signals and slots and inheritance where VCL uses events.
VCL components use absolute coordinates and Qt uses layouts. Of course, you could use absolute coordinates also with Qt, but the GUIs would be quite awful then.
VCL's TListBox and TTreeView classes are quite different from Qt's View and Model classes (although you could use QListWidget and QTreeWidget instead).
I guess it is much faster to design totally new GUIs with Qt than to create even a mediocre VCL-to-Qt converter. And the code will be much easier to maintain. I suggest that you take one VCL form of medium complexity and recreate that with Qt. After that you can make an estimation of the total recreation work. Also you will have a better understanding about the feasibility of a conversion tool, which you most probably would need to make by yourself.
Someone has written a tool to convert dfm's to qt ui files:
http://sourceforge.net/projects/dfm2qt4ui/
Its has a few small bugs but it can save several hours of time porting form designs. In some cases redesigning specific forms is preferable - but in many cases, having labels and roughly equivalent controls positioned for you saves a lot of point-and-click action.
I agree with the current consensus that automatic conversion from VCL to QT is not a good idea because the concept behind both is very different, and you are much better off learning "the QT way" and using that from the start.
However there is one major step that nobody has yet mentioned: refactoring! Before starting, make sure you refactor the original forms to remove as much business logic as possible and leave only what is really GUI code. It depends on how good your architecture already is of course, but the VCL designer tends to encourage putting as much as possible in forms (even going as far as having invisible "data forms" with non-visual components!), so you often find a lot of stuff in the form that shouldn't be there.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am new to programming. I have some Knowledge Of C++ and have learned Python.
Now i want to develop a Qt Gui Application. Which language should i use for Qt development C++ or Python with PyQt. I found Python to be easy language.
There is no definite answer to this question. With that said...
Pros and cons you often hear
Python is easy, C++ is hard (in
comparison to Python)
C++ is fast, Python is slow (so to
speak) performance wise.
In reality...
Both arguments can be true or false, you can make slow C++ program, but you can also make fast Python program, you could also say C++ is not that hard if you know it really good etc.
Qt is written in C++ so the documentation examples are in C++. This is not really a problem since it is easy to port this to Python. Although I've found that for example animations with state machine cause segmentation faults with PyQt and PySide is not all that stable yet.
So which one to pick?
Depends on your skill and assignment. If it is work you are doing go with what you know best and asses how much speed you actually need, not every app has a need for lower level code.
If you know Python, you could start building your prototype in Python, then port to C++ parts that you deemed slow and bind them back to the Python (using SIP for example) or even port the whole application to C++. This approach also makes good exercise.
But even if you wrote your whole app in Python I doubt you and your clients would ever notice the "slowness" or "fastness" if you go with C++. These things usually depend on skill of a programmer.
Conclusion
It's entirely up to you to choose what are you are most comfortable with and to understand what your app really needs, but both languages will do the job in most cases.
My subjective advice would be to go with Python and port to C++ if you really need to. Sole reason for this advice is that you do not need to type as much in Python as you do in C++ but this can also be seen as a silly reason.
I just finished a reasonably large project with PyQT... I think your choice should depend on three factors:
How big is your audience (less
than 100 installations? More?)
How much functionality do you need?
(Databases + graphics + plotting +
signal analysis + network access +
blah blah blah)?
How rapidly do
you need to develop, both now and in
the future?
C++/QT is great for 1) Big audience, 2) Low to medium functionality, and 3) Slow to medium development speed. Of course, you can do anything with C++ given enough time and money.
Python/PyQt is great for 1) Small Audience, 2) Any level (including high) functionality, and 3) Medium to fast development speed.
The benefits of Python/PyQt are that:
you needn't worry too much about datatypes, header files, and numerous other headaches that slow development, and you get to work in a world-class interpreted environment known for its ability to foster fast and robust development.
you can pull in massive 3rd party libraries like matplotlib, scipy, sqlalchemy, and configobj that can make complex tasks stupidly easy.
The downsides of Python/PyQt, IMHO, are that:
it may have slower performance in some applications (who cares? How often does that really matter?)
it may be substantially harder to deploy. Py2exe requires quite a bit of tweaking to get 3rd party libraries to work, and then you still need to build an installer and get that working. Then, every time someone installs your app you might have 10 to 100MB of unnecessary dependencies built into the thing.
Personally, I work in an engineering R&D environment where fast turnaround and extensive data analysis/visualization is key, and deployment is often to only a few dozen (tech-savvy) people. Python/Pyqt is the clear choice. But, if I were to be developing a simple, widely-deployed application like a bittorrent client or something, I'd go C++ all the way.
Other notes:
PySide (a free LGPL alternative to PyQt) is rapidly progressing and seems sure to blow PyQt out of the water; I'm planning to switch within the next few months but as of now some 3rd party libraries still aren't set up for it.
The documentation for Pyside is much better than for PyQt; if you need help on, say, "QListView", just search google for "Pyside QListView".
I'd recommend only using PyQt where you need to. E.g., don't mess with QtSQL (debugging is a nightmare) when you could just use SqlAlchemy, and don't screw with Qt's configuration system when you can use the awesome library ConfigObj.
The clear way to install Python/Pyqt/etc is using the distribution Python(x,y) ... it includes, among other things: Python, PyQt, Qt, Eclipse, PyDev, QtDesigner, Spyder, iPython, and many dozens of useful scientific and computing libraries. Compiling and installing this stuff on your own is not fun.
In addition to the arguments given by rebus, I would add that the development and maintenance time in Python is considered to be about 2-10 times faster than in C++ (in papers by Prechelt and Ousterhout). This is another significant advantage of Python, that you might want to consider.
My main reasons for choosing Python and PyQt4 are:
Readability: I can't think in C++. I truthfully cannot. Python, on the other hand, is pretty close to English, so I find it easier to skim and debug.
Speed: I find that Qt4 works almost identically in both C++ and Python when you're using it for simple applications that do little work on the inside. I coded a book binding application with Python, and since it is basically a frontend to bunch of CLI tools, there is no noticeable performance lag.
Rapid Development: If you can write it in words, you can probably write it in Python. When I had to implement a new feature in my program, I just opened up the source folder (which consists of only a few files. Compare that to C++'s header mayhem), and added it in. Sure I had to tweak it to work faster later on, but my main point is that because the language is readable, it is easy to code in, and hence increases productivity.
But just to weigh both sides equally, here's what I don't like about Python and Qt4:
Example Code: Good luck trying to find some sample PyQt4 applications. The community is pretty small compared to the C++ Qt community, so don't expect tons and tons of examples.
IDE: I code with Gedit, so this was not a big issue for me, but it did take some hacking while I was designing the GUI. You have to trick Qt Designer into promoting your widgets in Python-compatible ways (like proving fake header file names so that the modules import properly), and other things like that. Nothing to serious. My regret was the inability to use Qt Creator IDE. It's basically a GUI designer on steroids, but it looks nice and is like Visual Studio for Qt.
Speed: If your application does some serious heavy lifting, I'd stick with C++. Python is good for algorithmic things, but for raw number-crunching power, C++ is the winner.
Deployment: To compile Python applications into binaries, you need to do some magical stuff with PyInstaller, Py2exe, and Py2App. It's a pretty painful process (for me at least), but it's the price you pay for an interpreted language. C++ just compiles and is ready to go.
I hope this helps in your decision. Good luck!
Learn C++. C++ executes faster than Python, and the fact that Qt is not native to Python will also slow things down slightly. Also, there is at this point far more 3rd party software in C/C++ than in Python. You might not need it now but down the road you might want to link to some of this.
EDIT: Looking a little harder I see that EOL is right, there is a lot of Python support for major libraries, though not for everything as lunayorn points out. Nonetheless in all these cases the Python user is reliant on bindings, which by their nature may lag the library developments and add extra possibility for bugs.
And since I don't yet have the cred to respond to others' posts, let me say here that rebus' claim that it's all programmer relative and C++ or Python can be just as fast is completely (and dangerously, where speed is important!) wrong. Python's ease of use comes at an unavoidable performance cost, see the wikipedia entries on interpreted vs. directly executed languages. I know from direct experience that Matlab, which is interpreted in the way Python is, executes line for line 2 full orders of magnitude more slowly than C++. Python and Matlab are best considered as (and in the case of Matlab at least, originally intended as) interfaces to libraries coded in languages like C or Fortran. For serious, large programs where performance matters use C++.
everybody, I'm beginner in programming, I've just finished my course on C++, I want to train my skills and try to write some programs on C++ with graphic windows (not console programs, I did it during all my course), I want to start working with QT, is it good idea, or I need to begin with something simplier, thanks in advance
Qt is, among other things, a great framework for developing applications with GUIs. The only way to know if it is appropriate is to try it out. I suggest going through this Qt tutorial, which involves creating a simple game.
To begin with Qt is an excellent idea. Qt is already simpler.
You should begin with these official tutorials: http://doc.qt.nokia.com/4.7-snapshot/tutorials.html
GUI program is a big change from a console app - the difference is that you don't know when things are going to happen and in what order.
But Qt is a very good place to start, the signal/slot mechanism is much clearer (IMHO) than the hidden macros of MFC or some other gui toolkits.
I'm looking for comparisons between OpenCL and DirectCompute, but I haven't found anything. OpenCL's advantages of being cross-platform and having a wider range of supported GPUs don't matter to me. I'm fine with coding on Windows against DX11 GPUs only. Assuming that, what are the pros and cons of each API?
I know this question was raised before, but I'm looking for more details.
I'm not interested in CUDA, since I don't want to restrict myself to only Nvidia hardware.
Probably the biggest difference for a coder is that DirectCompute is programmed by a language which is similar to HLSL, and OpenCL is programmed via a C-like language.
Another difference to consider is that, generally, for commodity level GPUs, the DirectX support is better (faster and less buggy) than OpenGL support on Windows. This may translate to more stable support for DirectCompute, but really, this is just speculation.
Well the major advantage of OpenCL is that it is not just limited to graphics cards. You can make use of your multicore CPU, Graphics Card and potentially any number of other hardware acceleration devices (DSPs etc) all from the same program.
I'm not sure if DirectCompute allows that freedom.
The OpenCL cross-platform-ness is not just a detail, as the host code (the one calling the OpenCL API and submitting kernels) can itself be cross-platform (see link text, link text...).
Write once, run on any GPGPU, anywhere.
Otherwise the OpenCL tooling is really getting better, with an ATI Stream plugin for Visual Studio, the NVidia & ATI SDKs that contains tons of samples, etc...
Another option now is C++ AMP which gives you modern C++ syntax without a need for a seperate compiler while still preserving hardware portability. Please follow links from here for more info and feel free to post questions as you have them: http://blogs.msdn.com/b/nativeconcurrency/archive/2011/09/13/c-amp-in-a-nutshell.aspx
I use OpenCL because i can easily port my App to Linux but with DirectCompute this is not possible.
I think also that the performance of the OpenCL implementation will increase with time (that it comes at the same Level like CUDA for NVidia Cards) and also that the (driver)bugs will (hopefully ;) ) be eliminated with time.