Qt libs linking impact on speed of C++ code
-
Now my group is doing a small project assigned by our teacher. The task is to create a mini search engine in C/C++ which indexes text files and allows querying to search through them.
What we concern now is the impact of Qt libs linking upon the speed of the C++ code part. We have over 2000 text files (about 134MB) to index. With CLI-only version, the program takes nearly 80 seconds while in no-GUI mode of GUI version, the program takes 200 seconds. We are keeping these two version on "https://github.com/herophuong/Search-engine":https://github.com/herophuong/Search-engine. "no-GUI mode"'s code part of the GUI version is pure C++ and is exactly the same as CLI-only version's code. May some experts here can explain this for us. Thanks in advance. -
The question is if you are not comparing apples and pears?
Is your C++ compiled in release mode and optimized for speed?
I have noted in some of my applications that debug mode required quite a bit of time to load everything, while the release mode compilation was much faster. However, this was on Windows. -
bq. Is your C++ compiled in release mode and optimized for speed?
Yes, I compile both version with -O3 flag (which is default for release mode of CMake).
-
Hello
Try to use gprof to find out which function takes most time.
Also you may try to minimize using of text output (I mean information about current progress) during processing and avoid using of Qt containers inside your algorithm (as I've seen you don't do it). -
[quote author="ZapB" date="1335724253"]This is where a profiling tool such as valgrind comes in very useful.[/quote]
I have only used valgrind to detect memory leak. Thus I thought that this is the only function of valgrind. Thanks for remind me.[quote author="Wilk" date="1335730218"]Hello
Try to use gprof to find out which function takes most time.
[/quote]
Thanks for suggesting the tool. I will give it a try. -
Really thanks for all of you, guys. After using valgrind to analyze the run, I've resolved almost all bottlenecks on the program. The speeds of CLI-only version and no-GUI mode of GUI version are the same now and both of them have been reduced to 50s. LOL.
-
Though my question is still there because what I've done is only optimize CLI-only version and then merge the code with the GUI version (which means only the C++ code part is affected). Why are those speeds are not the same in the first place? May be I don't really need the answer for now but in the future projects, the problem may raise up in different situation.
-
You can see the code of main.cpp in gui branch. (The link is at the first post). If the --no-gui option is passed, the code path is redirected to not run the GUI loop and the program will run as the CLI version do. What I've asked is about the no-GUI mode of GUI version, not its GUI mode.
The GUI mode actually runs slower because of GUI stuff but I think I can not do anything about that. GUI needs to display progress so we don't feel it is frozen while it's indexing files.