[Darkskiez]

I used to work on the system at Google which processed deleted emails to ensure they are deleted across all systems it might have touched (eg, delete any calendar events created by the email, rebuild indexes, delete backup restore keys etc). Deleting an email was remarkably significantly more resource intensive compared to just leaving it alone, so this advice could only make the situation worse.

[JonChesterfield]

Do you happen to know why deleting lots of emails at once doesn't really work? Gmail that is. Select all 100k or so, delete, gets rid of the first N but not the rest, and N is order of some hundreds. It means delete old emails is far more time intensive than it should be.

[Izkata]

Try just leaving the tab sitting open for an hour. I have a suspicion the frontend works iteratively on them in the background, and the UI only updates occasionally. I haven't tried it with deletions, but with "mark as read" on a triage inbox this has worked with 40k+ emails.

[Darkskiez]

That system was what fed into the one I touched, which was an offline batch pipeline, so I wasn't tooinvolved with the Gmail internals that you're talking about. I know about 10 years ago many Googlers had the same sort of problems as you describe, I assume it's a tiny bit better these days, most of the backend has been replaced over that time. Expensive operations are often slow to ensure there is reasonable isolation between users, so you don't hurt someone elses experience when you do these things. They aren't frequent operations/CUJs so they aren't optimized either.

[qcnguy]

It would require a queueing and progress tracking infrastructure once a request gets too large to process in the span of a few seconds, which is a lot of stuff to build for a very rare operation.

[chrisjj]

Possibly worse for many users is that labelling has the same flaw.

And even if it does complete, you'll often never know. Upon command, Gmail tells you "I'll do it later". And often never alerts of completion.