Why is ddrescue slow when it could be faster on error free areas?

This question addresses the **first pass** of ddrescue on the device to be rescued. I had to rescue a 1.5TB hard disk. The command I used is: # ddrescue /dev/sdc1 my-part-img my-part-map When the rescue is started (with no optional parameters) on a good area of the disk, the read rate ("current rate") stays around 18 MB/s. It occasionally slows a bit, but then comes back to this speed. However, when it encounters a bad area of the disk, it may slow down significantly, and then it never comes back to the 18 MB/s, but stays around 3 MB/s, even after reading 50 GB of good disk with no problem. The strange part is that, when it is currently scanning a good disk area at 3 MB/s, if I stop ddrescue and restart it, it restarts at the higher reading rate of 18 MB/s. I actually saved about 2 days by stopping and restarting ddrescue when it was going at 3 MB/s, which I had to do 8 times to finish the first pass. My question is: why is it that ddrescue will not try to go back to the highest speed on its own. Given the policy, explicitly stated in the documentation, of doing first and fast the easy areas, that is what should be done, and the behavior I observed seems to me to be a bug. I have been wondering whether this can be dealt with with the option -a or --min-read-rate=… but the manual is so terse that I was not sure. Besides, I do not understand on what basis one should choose a read rate for this option. Should it be the above 18 MB/s? Still, even with an option to specify it, I am surprised this is not done by default. Meta note --------- Two users have voted to close the question for being primarily opinion based. I would appreciate knowing in what sense it is? I describe with some numerical precision the behavior of an important piece of software on an actual example, showing clearly that it does not meet a major design objective stated in its documentation (doing the easy parts as quickly as possible), and that very simple reasoning could improve that. The software is well know, from a very trusted source, with precise algorithms, and I expect that most defects were weeded out long ago. So I am asking experts for a possible known reason for this unexpected behavior, not being an expert myself on this issue. Furthermore, I ask whether one of the options of the software should be used to resolve the issue, which is even more a very precise question. And I ask for a detailed aspect (how to choose the parameter for this option) since I did not find documentation for that. I am asking for facts that I need for my work, not opinions. And I motivate it with experimental facts, not opinions.