Earlier quoted context omitted.
If you're set on linear search then you would see the same performance for a simple search box too, I don't see how type-ahead changes it. For big folders you will still need an index, imagine now you sorted the list by reverse alphabetical, typing an 'a' is still going to be slow when you're at the top.
Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all. That's why it is so fast in practice, it's instantaneous (as far as screen refreshs go) on every file manager I've ever used. Recursive search however, does have to touch the filesystem, and does have to touch it massively for directories that contain tho…
So would a simple search in that folder? I don't see what is special about type-ahead here. I'm not talking about recursive search, that can already be disabled in Nautilus if you don't want it. I think this another reason is why it's bad that people get so outraged about this, a lot of the anger is directed at recursive search when really the solution there is to just fix or disable recursive search. Bringing back type-ahead is not the only way to deal with the problem. Another option would be to speed up recursive search so that it uses your suggestion first to do a fast search and quickly display results from the current folder before recursing, that would be the best of both worlds.
>By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory.
That could also be solved with an intentional search option to search by prefix, maybe with a button and bound to a certain key that makes it obvious and not confusing what's happening. I'm not saying it's bad to search by prefix.