Yes it helps.
It is not so easy to tune these parameters for an optimal performance.
The effect that your are seeing has to do with Java's garbage collector.
In order to improve speed you can play with the following parameters:
--java-mem-size -> The bigger the faster (the garbage collector will work less often).
-nw (number of windows) -> The bigger the slower with better resolution on the results and less Java memory needed. The smaller the faster with less resolution on the results and more Java memory needed. Basically, every time the end of a window is reached, we launch a thread that computes the corresponding statistics for the window (please, read this for more info: http://qualimap.bioinfo.cipf.es/doc_html/analysis.html#advanced-parameters). Unfortunately there is no general rule to set an optimal value since it will depend on the data being analysed (peaks of coverage imply more memory and time needed for one window).
-nt (number of threads) -> The bigger the faster
-nr (number of reads in the chunk) -> It controls how many reads are stored in RAM before they are computed. We do this to be able to keep the threads busy as much time as possible since the I/O from the disk is very time consuming. This should therefore be optimized with respect to the number of threads the Java memory size and the number of windows in order to minimize the time where threads are idle.
Please note that the garbage collector together with the I/O from disk are the two bottlenecks in Qualimap performance. It is a priority for us to improve this in future versions. Any idea is most welcome :-)