Trim off 1.15 seconds of page load and 1/2 mb of data by removing autocomplete data

The auto complete data is very large and completely unnecessary. It loads 462kb of data, 99% of which you will never use. It loads 2215 emojis, 2724 issues, 163 merge requests, and all 56 members. For now. It gets larger as we get larger. This query takes. 1.5 seconds (on gitlab.com). This data is used for the auto complete data so you can use # to reference an issue or ! to reference a merge request or @ to reference a user or : to reference an emoji.

We have two choices as I see it. Load the auto complete data 1 by one if they use it. So if someone types a @ we load the username data only (once). If someone types a # we load the issue data only etc.

The other option is to querying on the fly. which could be very quick too. If we query on the fly we do a search via ruby for @job and it returns {username:@JobV,name:Job van der Voort}.

If someone never does an autocomplete then the data shouldn't ever be loaded.

I think this issue is of highest importance.

cc @DouweM @JobV @dzaporozhets

Title changed from Trim 1.15 seconds of page load and 1/2 mb of data by removing autocomplete data to Trim off 1.15 seconds of page load and 1/2 mb of data by removing autocomplete data

Added ~18308 label

for querying on the fly. If I type @j the query would be WHERE username LIKE 'j%' LIMIT 5. That should be very fast.

@jschatz1 clearly. Please do this asap :)

we changed autocomplete things a few times in the past, because waiting for @ to load on GitLab.com was just waaaay too long. So keep that in mind ;-). It seems that @DouweM 's suggestion should fix that.

Also discussed in https://gitlab.com/gitlab-org/gitlab-ce/issues/13299

Milestone changed to 8.6

for querying on the fly. If I type @J the query would be WHERE username LIKE 'j%' LIMIT 5. That should be very fast.

When doing so please stick to the approach outlined in http://doc.gitlab.com/ee/development/sql.html#using-like-statements.

mentioned in issue #14298 (closed)

Do you guys want me to write the rails queries? Or would someone like to write the rails for this and I write the frontend?

Removed ~18308 label

@jschatz1 was the autocomplete data not loaded async? Did this really affect page load time?

Added ~18308 label

@sytses It is loaded async. It should not affect load time. I am going to double check here, because it seems like it does.

@sytses @JobV I was completely wrong it has nothing to do with the initial page load time. I got a little too excited there.

Status changed to closed

Still, it causes a lot of mostly unnecessary traffic.

Status changed to reopened

@pbr I agree. I think we should still load this data better instead of all at once. But it isn't as much of an emergency.

@jschatz1 Will this be done in time for 8.6 release? Do we have a merge request for this yet?

Milestone changed to 8.7

@voarsh It turns out that I was wrong about this and it is not loaded sync, but async. Therefore it is not going to save 1.5 seconds of page load time. It is still something we should fix, but I've moved it to 8.7.

Oh. I missed the part where you described it above:

It is loaded async. It should not affect load time. I am going to double check here, because it seems like it does.

I was completely wrong it has nothing to do with the initial page load time. I got a little too excited there.

mentioned in issue #14423 (closed)

mentioned in merge request !3445 (closed)

Status changed to closed