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)?