Wdired is really nice for batch renaming files, but I have noticed that
in case there are lots of files, starting wdired mode and finalizing
changes can take a while. Sometimes I switch to wdired mode just to rename
a single file. On my machine, a directory with ~700 - 800 files causes
a noticable delay. I haven't measured but it is in range of 2-3
seconds I would guess. I had one directory with almost 2000 files and
when tested it took quite a bit of time.

I traced it down to how dired/wdired use text properties to controll if
text is writable or not. When switching to, wdired goes three times
through entire buffer (filenames, perms and symlinks) and changes text
properties to writable text.

I have rewritten those few functions to drop to wdired mode to only work
on a line under the point; it is just quick copy/paste hack. It
works fine for my needs and wdired starts without noticable delay, but
there is one cosmetic detail: despite me changing properties only for
current line, wdired still let me edit other text in dired buffer
itself.

When saving changes, it properly saves only the intended line. I don't
seem to be able to find which property affect that behaviour, wonder if
someone can help in that regard?

Another question: is this interesting to add to wdired? It makes Emacs
behave a bit more like standard file managers; they usually bound F2
(for example Dolphing) to file-rename operation.

Error checking is needed to handle cases when point is not in a line
with a filename.