I bundle identical tags together to make the process more efficient, and believe it or not, I’ve actually made the whole update process a lot faster in recent months! Unfortunately, it still all adds up–I assume, to about 100 I/O reads per tag. Not to mention a little extra overhead with every update, and, I think, probably some regular SQLite journaling overhead. All of these requests need an index lookup, and anything that changes the database needs to update those indices, which will need more reads. Every time it adds a tag, it needs to look up and initialise previous instances of the file hash and tag, cross-reference with files already in the database, actually insert the tag into the database, and clear out invalid caches. My public tag repo currently has about 6.7 million tags, which means your client needs to download and process 6.7 million rows of data. The way the hydrus database stores tags is more CPU- and HDD-intensive than other tagging applications, and moreso, the network shares all tags to all clients. Anonymous asked: This looks like a good software but I'm trying to use the public tag repository you've included, and it's been "synchronizing" for a day now and the programs total I/O read operations is at 800 million.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |