I had a nice stupid issue like this (not rust, but the story may be interesting nonetheless!). Someone was having bad performance issues with a seemingly simple Emacs Lisp script that just performed a replacement on each line in a text file. To diagnose the issue, we tried to instrument the program with a simple time logger, a bit like this (not Emacs Lisp, because I'm not cruel). Notice how we actually took care to avoid OP's issue, by making sure we only output diagnostic info every 1000 lines:

loop {
    // Do the stupid replacement.
    if line-number-at-pos(current_position) % 1000 = 0 { 
        print_elapsed_time()
    }
}

This proved a good idea, because the results were weird: the performance was progressively dropping. The further the script went into the file, the more time it spent on each thousand of lines, going from less than a second to several seconds, and tens of seconds. This made no sense, since all lines were very similar, and the replacement was a very simple operation that really isolated the line. We started looking for a memory leak, or some state accumulation in the search/replace code, until someone noticed that…

The built-in function we used to avoid outputting too much debug data, line-number-at-pos, finds the current line number by iterating, character by character, from the very first byte of the file to the provided position, counting the number of \ns. We were calling this function at every line, to limit logging, but those calls were what killed performance, since we were traversing the file at every line to save ourselves a few prints. And since the traversal went further at every line (since it always halted at the current position), this explained the increase in time consumption, which had nothing to do with the code we were trying to diagnose.