Topic on Talk:Edit Review Improvements/New filters for edit review

I don't mind the new interface (can't say I've found a use for it either), but I've had to disable it because of the poor performance. For me it takes 5-10 seconds for the edit filters to load (perhaps because I have a lot of pages on my watchlist?), and during that time the whole watchlist is unresponsive. Like most Wikipedia addicts I'm constantly opening/reloading my watchlist so this gets really irritating really fast. By contrast the old filters load instantaneously for me. If the plan is to make this the new default I really hope something can be done to it speed up before it leaves beta.

The load wait when you first arrive is annoying and for me the filters are a hindrance. But I can't find the instructions on how to switch it back to the old, fast, alpha, better interface :(

If you go to the "Beta features" tab in your preferences, you can untick "New filters for edit review" to disable it. Make sure you also untick "Automatically enable all new beta features", otherwise it will instantly re-enable the new filters when you click save!

Thanks for the reply, but it didn't work for me :( I'm using this on Wikimedia Incubator.

The slowness of this tool makes it tedious to use. I like the idea but am unable to tolerate the ~5 second load time in the workflow habits I have for using my watchlist.

We just fixed a longstanding bug that made ORES searches much slower on Watchlist, so if you have been using any ORES filters, you should notice a big change.

Meanwhile, our tests show that the average WL load time with the new UX is around 3.5 secs on en.wiki (check the top graph on the right). According to different tests, that is about a second slower than the old UX on first page load (see cell E50) and about a half second slower on subsequent, "hot cache" reloads (E59). Oddly, Recent Changes loads faster on average, so we continue to look for ways to speed Watchlist up.

Thinking about this speed issue more, I have a question. It sounds like this might be how you are using WL: to check a page, you click on it and go to the page, then use the Back button to go back to WL. Is that right? If so, it's understandable that load time would be an important consideration, since you are reloading the entire WL each time. (As noted above, because you are coming from a different page, this causes the full, "cold cache" reload, which is the slowest.)

I wonder if you might instead consider using right-click or the equivalent to open a new tab when reviewing changes?

A new feature we added might make this approach work particularly well. You may have noticed the blue "View Newest Changes" link, which appears right above the search results. The link appears whenever new changes are available. WL looks for them every few seconds in the background. So if you don't see the link, there is no need to reload the page; you can be certain you are seeing the latest. And if you do see the link, then clicking it just fetches the new results, which is faster than reloading the whole page.

I know this would require a change to what may be a longstanding routine. But other than that, what do you think? It seems like it should be a net timesaver, since it would entail fewer page reloads overall (even if the ones you did have to do were a half sec slower). @Joe Roe, @Bluerasberry, if this technique wouldn't work for you, I'd genuinely like to understand why? Thanks.

Thank you for the detailed response! I use Wikipedia throughout the day to procrastinate while I'm working, so my workflow (such as it is) is basically to open my watchlist every half an hour or so, look through any changes either using the popup script or new tabs, then close it again. So no I don't leave and reopen the page frequently. If I'm actively editing I'll leave it open in a tab and reload every now and again.

I had noticed the "View Newest Changes" feature, and it is cool, but for me it doesn't make any appreciable difference to the load times. To clarify, above I was talking about the time it takes the edit filters to load after the watchlist itself has rendered (during which time the watchlist is unresponsive). For me at the moment, it takes about 4 seconds for the page to load, then less than a second for the old edit filters to load (in fact until now I hadn't noticed there was a lag). With the new filters enabled, it takes about 5 seconds for the page to load (I timed it a few times to be sure it is actually longer), and then after that a further 9 seconds for the filters to load. It's the second part that's really annoying, and it's only about 2 seconds quicker if I use the "View Newest Changes".

So I'm not sure changing my workflow would help. Also, I did these timings just now, so the change to ORES unfortunately does not seem to have made a difference – I don't think I am/was using any ORES filters. I can't explain why my experience has been so different to your stats. I guess I'm just an outlier?

I am very sorry to hear that delay is hitting you. Yes, you appear to be an outlier, but that doesn't mean we want to ignore your situation. Two things: I'm pinging our lead engineer, @Catrope, to see if he has any ideas for following up on this, and can you please say how many pages are on your Watchlist? Also, just checking, are you using a reasonably fast broadband account?

Thank you. I have 5,031 pages on my watchlist, and a 24 mbps broadband connection.

@Joe Roe Thanks for the detailed breakdown of the loading time, that helps a lot. It's remarkable to me that the second stage takes 5 seconds. It doesn't take that long for me. I'd like to investigate that, and I have some questions:

1. If you use safe mode (a URL parameter that disables gadgets), does that make it any faster?
2. Which browser do you use?
3. After the watchlist finishes loading the address bar will display a URL that looks like /wiki/Special:Watchlist?lots of stuff here. Could you send me that stuff?

I also noticed that it takes about a half-second longer for me than it used to, so I'll try to figure out why that is.

@Roan Kattouw (WMF) Worse, the second stage takes 9 seconds!

1. Safe mode doesn't seem to make a difference. It's still 5 seconds to render the page + 9 seconds for the new edit filters to load.
2. Chrome, the 64-bit stable branch
3. ?hidebots=1&hideWikibase=1&limit=1000&days=7&damaging__likelybad_color=c4&damaging__verylikelybad_color=c5&highlight=1&urlversion=2

Thanks for taking the time to investigate.

I've done a bit of messing around. Removing the two ORES highlighting filters (so the query string is ?hidebots=1&hideWikibase=1&limit=1000&days=7&highlight=1&urlversion=2) shaves about 3 seconds off the time it takes the edit filters to load. That's still a bit long for me to stick with the new filters (5 secs + 6 secs), but perhaps it means something to you guys.

@JMatazzoni (WMF) @Roan Kattouw (WMF) I see this is being switched on properly now. Has this been fixed?

Hi@Joe Roe, thank you for following up on this. A few questions:

1. Could you tell me a bit about your computer – RAM, CPU, and operating system?
2. What is the load time like if you set the limit to 100, and at 250?
3. Do you see the same performance issues on Special:RecentChanges with the same query that you use on Watchlist?

I'm pinging @KHarlan (WMF), who's also looking into this issue.

@Joe Roe @Bluerasberry thanks again for your feedback and help with diagnosing the performance issues. We're working on a few fixes, you can track our progress at https://phabricator.wikimedia.org/T197168

@Joe Roe @Bluerasberry we've deployed a set of fixes to address performance issues, if you have time we'd appreciate your feedback. Please look at "Send us your performance traces" in https://phabricator.wikimedia.org/T197168 for instructions on sending us your feedback. We are still investigating a few more optimizations as well but hope that you will see an improvement with the code that's been deployed already.

@KHarlan (WMF) thanks for whatever you can do.