As far as I know, this is not really a "bug". Server timing out is precisely the way to deal with expensive requests. @Mike_Peel Here's a handy link to your raw watchlist: c:Special:EditWatchlist/raw.

This reminds me of T265347, T95888, T47380, T68212, T69123. And T41510.

Does https://commons.wikimedia.org/wiki/Special:EditWatchlist/raw work? :')

I have had a similar problem on en.WP with about 19K items on my watchlist. Neither Edit or Edit raw would work - always timed out. And once that happens there is no way to prune your watchlist apart from article by article unwatching, which is what I did probably thousands (literally) of times until I finally got it to the point where in a lucky moment it finally opened with Edit raw and I zapped a lot of them. I understand why we need to have timeouts as a server may genuinely be malfunctioning but I think the time-outs should be relative to the size of the watchlist, or retrieve the watchlist in chunks, each of which should be possible within the current time-out.

The raw watchlist loads fine for me, although I haven't tried saving it (it would be a lot of work to rebuild it manually if the saving went wrong!).

In theory having a paged UI for watchlists (split by namespace, then by title prefix) doesn't seem super hard. Not sure if it's more convenient than raw editing though.

Two big advantages of the normal EditWatchlist over raw are being able to see which items have been redirected or deleted, without having to check them manually.

In T309446#7969104, @Mike_Peel wrote:

Two big advantages of the normal EditWatchlist over raw are being able to see which items have been redirected or deleted, without having to check them manually.

I guess this is because you see the red links (or not?)

I added 10k items to my watchlist on testwiki to play around with this a little bit
And I profiled the loading of the page https://performance.wikimedia.org/xhgui/run/view?id=62968ac1c0fce6c743114335

Looking through the profile it looks like a bunch of time is spent in the MediaWiki LinkCache https://performance.wikimedia.org/xhgui/run/symbol?id=62968ac1c0fce6c743114335&symbol=MediaWiki%5CPage%5CPageStore%3A%3AMediaWiki%5CPage%5C%7Bclosure%7D
Looking further up the tree this ends up being on buildRemoveLine https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialEditWatchlist.php#L654
So in essence the thing that makes this page expensive to render is the fact that link needs to be rendered and the check needs to happen to see if the page exists or not.

In T309446#7968778, @Tgr wrote:

In theory having a paged UI for watchlists (split by namespace, then by title prefix) doesn't seem super hard. Not sure if it's more convenient than raw editing though.

This would indeed lead to slightly smaller lists of items to iterator over to generate these lines

The only other option that I would really see would be some form of batching in the lookups in the loop that makes the page
https://github.com/wikimedia/mediawiki/blob/0bacedd339e2f335f46a114d045a3a168447b9ae/includes/specials/SpecialEditWatchlist.php#L651-L657

This would probably require some abstraction or alternative to https://github.com/wikimedia/mediawiki/blob/0bacedd339e2f335f46a114d045a3a168447b9ae/includes/page/PageStore.php#L139 that could be used (PageStore::getPageByName)

In T309446#7972368, @Addshore wrote:

This would probably require some abstraction or alternative to https://github.com/wikimedia/mediawiki/blob/0bacedd339e2f335f46a114d045a3a168447b9ae/includes/page/PageStore.php#L139 that could be used (PageStore::getPageByName)

Wouldn't LinkBatch cover what we need (red links and redirects)?

In T309446#7973997, @Tgr wrote:

In T309446#7972368, @Addshore wrote:

This would probably require some abstraction or alternative to https://github.com/wikimedia/mediawiki/blob/0bacedd339e2f335f46a114d045a3a168447b9ae/includes/page/PageStore.php#L139 that could be used (PageStore::getPageByName)

Wouldn't LinkBatch cover what we need (red links and redirects)?

For normal pages the special page is using a LinkBatch, but for pages in the File namespace each file is additional queried explicit as needed by Title::isAlwaysKnown to make foreign files blue/red.

It should use a pager.

This might be simplified by filtering by namespace rather than grouping by namespace

In T309446#10883877, @Cparle wrote:

This might be simplified by filtering by namespace rather than grouping by namespace

Not if you watch thousands of pages in just one namespace. Which I imagine is the case for most editors for whom this is a problem. What is needed is pagination.

Oh I agree - I was thinking that pagination-plus-filtering might make more sense than having separate pagination for each namespace

(in the context of @tstarling 's comment just before mine)