Issue: Admin cp: Prefix create/delete post-save processing stage lasts a long time. Possible performance issue?

On a copy of VW 4.1 Beta 1, after waiting an extensive amount of time to save a prefix (#2), I went back to add another one and noted down the save begin and end times. The processing that occurs after creating a prefix lasted around 10 minutes on this occasion. This is with the wiki having only 3 prefixes, 6 areas and 9 pages (according to Special:AllPages).

By comparison, the upgrade process for this same forum instance from XenForo 2.1.1 to 2.1.2 took 6 minutes. Because the VW processing stage (after creating/deleting a prefix) takes longer to complete than an official XF upgrade despite a small sized wiki, something doesn't seem quite right. There seems to be some kind of performance issue with the jobs after creating a prefix. Comments/thoughts?

Throughout the prefix processing stage, there were upwards of 240 XHR entries in the browser's network developer tools relating to admin.php?tools/run-job. I can't tell whether this is normal, though 240 does seem very high for 3 prefixes + 6 areas + 9 pages.

---

Earlier today, a few days after the above attempt, I tried adding and deleting prefixes again with a different XF2.1/VW instance that has 37 pages. Adding or deleting a prefix this time resulted in the processing stage taking 15-18 minutes to finalise.

The xf_job table lists an entry for vw\vw\Handler\Job\Defer. The vw_defer table has a number of rows with what seems like duplicate values (not sure whether this is a bug ). I counted 16 rows with identical dateline, defer and data contents. One by one, each row's data field contents is changed and the complete field is set to 1.

---

PS: This testing was conducted on a consumer NAS product, running Apache 2.4.39 with PHP 7.2.13. I expect operations to be slower than a dedicated web server, but not this slow. General XF performance is fine for testing with this environment.