Because this is only used in HCD detection and the upstream is not considered. The lowest downstream tone ever searched for is something around tone 40, and the highest so far is 88. I am not sure whether or not I’d get a very minor speed increase from chopping off the highest tones, say above 100 (a bit higher than 88 just to be safe in case of future changes). Since the highest part is not searched only discarded, I’m not sure there’s much benefit to be gained.
Coming back to the lowest tones, I’m assuming the time cost of searching for a line with tone=x=nn is the cost of matching, searching for newlines, then skipping any white space and checking for a digit, then matching the decimal number x value. How quickly you can scan forwards and reject non-matching lines determines the performance, so I’m thinking that chopping of the first part decreases the number of times around the loop. Even with this initial truncation, one would still have to go round say ( 88 - 35 ) times to find line tone=x=88 if 35 is the first line, that compares to 88 + n_initial_non_record_lines = 88 + 8.