Qt libs linking impact on speed of C++ code
-
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.