I'm relatively new to it, but I did do a stress test once. Loaded several hundred (over a thousand?) files of source code. Apart from the initial conversion to nodes, it was fairly performant. Doing a cff on the whole code base was pretty fast.
I did have to disable the setting to poll for file changes, though. When you have so many files open, that will seriously slow things down. I believe this was over a network too (i.e. the files I was opening were on a remote machine).
Number of files doesn't really matter, at the end they all go to the same outline. Number of notes, complexity of the outline (clones), content loaded in the editor, that are hard numbers influencing the perfomrmance. But of course it also depends on the hardware.
On my old rusty system I usually experienced lags starting with some 10k nodes. Editor usually lags when content with longer lines (some hundred characters) or content with many lines (some hundred or thousand lines) is loaded. Directives in the content are influencing behaviour, as also the used syntax highlighting. Even activated features are influencing things of course. The declutter-code for example seems horrible ineficient and called way to often I think, but I haven't digged deeper there yet.
Though, it should be noted that in the last months some improvments were in progress, and the actual developer-version seems to behave a bit better on certain aspects. So version is also a factor.
My personal rule is to slim down leo-files when they go >10 MB.
I'm relatively new to it, but I did do a stress test once. Loaded several hundred (over a thousand?) files of source code. Apart from the initial conversion to nodes, it was fairly performant. Doing a cff on the whole code base was pretty fast.
I did have to disable the setting to poll for file changes, though. When you have so many files open, that will seriously slow things down. I believe this was over a network too (i.e. the files I was opening were on a remote machine).