This can either be 'idle time' or 'shutdown time'. I have attempted to offload most of the background maintenance of the client (which typically means repository processing and internal database defragging) to time when you are not using the client. Make sure you know what this is and that you do it. If you run on an HDD, keeping it defragged is very important, and good practice for all your programs anyway.

Similarly, if you run two clients on the same computer, you should have them set to work at different times, because if they both try to process 500,000 tags at once on the same hard drive, they will each slow to a crawl. Running hydrus on your games computer is no problem at all, but if you leave the client on all the time, then make sure under the options it is set not to do idle work while your CPU is busy, so your games can run freely.

In general, the client works best on snappy computers with low-latency hard drives where it does not have to constantly compete with other CPU- or HDD- heavy programs.

I am always working to reduce lag and other inconveniences, and improve UI feedback when many things are going on, but there is still a lot for me to do. I don't put training wheels or limiters on the software either, so if you search for 300,000 files, the client will try to fetch that many.įurthermore, I am just one unprofessional guy dealing with a lot of legacy code from when I was even worse at programming. To add millions of files and tags to its database, and then to perform difficult searches over that information, it needs to use a lot of CPU time and hard drive time-sometimes in small laggy blips, and occasionally in big 100% CPU chunks. The hydrus client manages a lot of complicated data and gives you a lot of power over it. Reducing lag ¶ hydrus is cpu and hdd hungry ¶

For android download Hydrus Network 537