/baltop would cause 2 or 3 sec (sometimes even 4 sec) TPS drop while "sorting" with only 90k userfiles.

That's on MC-32 (with SSDs and low load) ...

I'm assuming "looping" over all files "at once" (and reading them without pause) is bad idea (for IO and would prob. cause spikes on CPU load too) maybe getting 10k files and sleeping for 1 sec and then another 10k files, etc... if sorting is done async?

I've been looking for this for days and ATM /baltop would instantly kill our TPS...

Essentials's Baltop (unless someone broke it) runs in another thread, so doesn't actually directly effect TPS.

If you are using an additional economy plugin, you should probably use 'their' version of baltop, as the essentials version would have to request the balance of every users balance from the other plugin, which could cause lag if the other plugin can't handle those requests efficiently.

If you are using Essentials only, a timings report could be useful, run a /timings reset, followed by a /ebaltop force, and then a /timings merged, and link the report here.

Note to EssX team:
If they are in fact using Essentials's built in eco, it could be due to some slow uuid lookup. Since the userdata has both the name and uuid stored in file, there might be a way to tweak the object loading to skip the uuid lookup.