That comment misses the real win: we’re not paying the full cost of address derivation + Base58 on every candidate, only on the tiny fraction that passes the c-bit filter.

1. Linear scan does, for each x:  
   - point multiplication (x·G)  
   - SHA-256 → RIPEMD-160 → double-SHA-256 checksum → Base58 encoding  
   - that’s dozens of heavy operations per key.

2. Prefilter does, for each x:  
   - point multiplication (same)  
   - only SHA-256 → RIPEMD-160 (the H160)  
   - extracts c bits, compares to target filter  
   - that’s one cheap H160 per key.  
   - then, in ~1/2^c of cases, it does the full address derivation+Base58.

So you dramatically cut out the expensive checksum+Base58 for ~95 % or more of the keys. That is a genuine saving!

Moreover, you don’t even need to Base58-encode on the final match, you can compare the 20 byte H160 directly to your target hash160. But that only further speeds up the tiny fraction that passes the filter, it doesn’t eliminate the savings of the filter itself.

But of course we can always improve, we never need to generate the Base58 string for the final comparison, and it’s sufficient to compare hash160(pubkey(x)) directly to your HASH160_TARGET. Besides, nobody asked me for a fully fledged GPU accelerated script or anything like that. This just shows that linear is not the best.