Initial tag load performance improvement

[luceos]

Links flarum/framework#2177

Current situation

On hitting the Forum index, the ShowForumController gets its payload enriched from flarum/tags:

tags/src/Listener/AddForumTagsRelationship.php

Lines 53 to 56 in 164d67b

	$event->data['tags'] = Tag::whereVisibleTo($event->actor)
	->withStateFor($event->actor)
	->with(['parent', 'lastPostedDiscussion'])
	->get();

This code loads all tags and some of its relations. For small forums this isn't really an issue. But forums that have a ton of subtags this affects performance.

New situation

I've decided to exclude subtags, but include helper tags. The helper tags are limited to three, unless you click "more tags" which redirects you to the tags page. We could potentially improve this logic further by only including the 3 tags with the most discussions (withCount('discussions')), but that would need some optimalization as subqueries can't use limit in MySQL.

I am currently deploying this branch to the Bokt staging environment. Query count reduction in Bokt staging: 411 to 52. 163 tags.

• Permission Scope js

[tankerkiller125]

I'm assuming that on clicking a parent tag the child tags will get loaded in? (I haven't had time to test locally)

[dsevillamartin]

This is definitely not ready for merge. When clicking on a tag, only those with existing discussions that load appear (because they are included in the /api/discussions response - we could improve performance times by not including already-loaded tags in API response, not sure if possible).

Sometimes a second child tag appears under another tag - not sure why that one is loaded 🤔.

[askvortsov1]

Iirc, there isn't currently a call to the tags endpoint in the tags frontend (at least not on the tags page I think)? How are additional tags being loaded?

Also, I'm still confused why the tag states can't be loaded alongside the tags themselves in a single query. I'm in favor of not loading everything at once for reasons of scalability and reducing payload size, but I think the multiple queries thing is the bigger issue when it comes to performance. Does it still occur when no extensions other than core and tags are enabled?

[dsevillamartin]

@askvortsov1 Additional tags are only loaded when a discussion has the tag.

[luceos]

Hm, right I didn't look far enough beyond the first page. Will look into that.

[askvortsov1]

Also, if the page we're on IS the page for a parent tag (which is possible via custom homepages), perhaps we should load those too?

[dsevillamartin]

@askvortsov1 Well it'd also be a parent tag if you directly visit /t/. I think this should also be extensible.

[luceos]

@datitisev what exactly do you mean with extensible? What should be extensible?

[dsevillamartin]

@luceos 🤔 i don't know.

I assume deciding which tags get loaded, because of this comment I was replying to:

Also, if the page we're on IS the page for a parent tag (which is possible via custom homepages), perhaps we should load those too?

[luceos]

My pr adds a ShowTagController to load one tag through the api. The parent include (relation) already existed, I've added children in addition. There are a ton of other changes and I still need to tackle some minor things (like the permission grid tag selection). Other than that, it seems to already work much better than before.

[askvortsov1]

TODO: Add tag loading logic for the composer and selection modal.

I feel like this could also use pagination, but I think that might be better in a separate PR after we get @datitisev's PaginatedList utils class merged.

[askvortsov1]

Current setup:

~50 top level primary tags
~25 primary subtags for first 20 top level primary tags
~3000 secondary tags

Load differences:

• On a regular discussion page: ~5.1s => 2.2s
• On the discussion list: ~5s => 1.7s
• On a top-level primary tag page (with 25 children): ~5s => ~2.2s
• On a child tag page (with 25 siblings): ~5s => ~2.2s
• On the "all tags" page: ~4.9s => 5.1s

This still feels way too slow, especially the regular discussion / discussion list pages (with no tags, they load in ~200ms).

Also, some logic issues are still present with load. Taking this back into draft mode.

[askvortsov1]

And back out of draft

[SychO9]

Looks good to me, nice work!