Public Test Repo Tags slow down client

Name
Email
Subject
Comment *
File	Select/drop/paste files here
* = required field	[▶ Show post options & limits] Confused? See the FAQ.

Embed	(replaces files and can be used instead)
Options	Do not bump (you can also write sage in the email field) Spoiler images (this replaces the thumbnails of your images with question marks)
Password	(For file and post deletion.)
Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf Max filesize is 8 MB. Max image dimensions are 10000 x 10000. You may upload 5 per post.

Public Test Repo Tags slow down client Anonymous 12/19/15 (Sat) 16:34:43 No.1600

Syncing to the PTR Tags only causes searching and even tagging to become unbearably slow. Tagging will take roughly 15~ seconds to open, which is simply unusable.

Am I doing something wrong? Or is this simply a problem?

hydrus_dev ## Board Owner 12/19/15 (Sat) 18:53:43 No.1603

File: 1450551223046.jpg (102.76 KB, 1018x1191, 1018:1191, e0f238e1bd8f5adb4a2d0d560f….jpg)

It is probably a bit of both. The client is laggy with the PTR, but there are also some things you can do to speed it up. I wrote a little guide last week to help, if you haven't seen it yet:

http://hydrusnetwork.github.io/hydrus/help/reducing_lag.html

But my code is very unoptimised in many places. In next week's 'next feature' vote (I will post the vote link on the release post), there will be several things related to improving speed.

Anonymous 12/19/15 (Sat) 19:09:50 No.1604

>>1603

Yeah I took a look at that and tried fiddling with the settings for a good while before posting, nothing seems to help. I confirmed PTR was the problem by making another clean install and imported the same files. Search and tagging was practically instant. Then I synced the 2nd clean install to PTR, and it had the same lagging performance of my original.

I wanted to test if the issue would persist if I copied all the tags to local and removed PTR syncing, but I wasn't able to.

I used Review Services > Remote Tab > Perform a service-wide operation > copy all mappings to local tags GO, however seemingly nothing would happen. I would then close/restart the client to see if it would perform it as part of the maintenance work and what not, and a blank square would pop, almost like the normal maintenance work. It seems freezes however, as the client would use a large amount of CPU, and even after leaving it alone for a few hours, nothing would change.

hydrus_dev ## Board Owner 12/20/15 (Sun) 20:10:37 No.1613

File: 1450642237738.jpg (384.24 KB, 1686x1239, 562:413, f1cae57dd437f1ad3ffb830eae….jpg)

>>1604

It sounds like my code is the problem, then. The PTR has grown faster than I expected, so what worked well for 4 million tags is groaning at 25 million. If it is the thing you care about most, please vote for optimisations on the coming poll. You can also send me a profile, if you like.

I have just remembered that improving the service-wide operation dialog (which was originally created mostly for debug, and is very ugly all around) was something else I wanted to put on the poll, so thank you for mentioning it!

I don't think that dialog gives much gui feedback on what it is doing. You might have bloated your db by a couple of GB and slowed your indices a little further by cloning all your mappings. If you feel brave, you can probably undo it by deleting all local mappings, but if you have a more complicated situation (like you already had a lot of local mappings you would prefer to keep), let me know, and I'll walk you through how to specifically only delete the mappings you duped.