ArthurTaylor added a comment.
I've done some more investigation here over in T356896 <https://phabricator.wikimedia.org/T356896> - I'm pretty certain that this is nothing to do with an external cache or about localisation. It seems just to be that we have big test suites and a greedy internal cache of objects in the `ResourceLoader` - multiple copies of 30MBs of strings are created during the module building and Javascript minification process. I added a patch there and it moved the dial a little bit. I can keep digging and trying to optimise things, but my question would be how much effort it makes sense to spend here to optimise a case that we don't have in production (where we're not trying to serve 30MB of QUnit tests), vs. simply upping the memory limit for the CI containers for QUnit runners. @hashar, @Lucas_Werkmeister_WMDE - what do you think? On the one hand, I can see that it's good to run the tests in the same constrained environment that we run production in - not doing that will cause some issues to slip through the testing net. On the other hand, QUnit and our current ResourceLoader implementation is a pretty memory-hungry combination and we seem (according to my research at least) just to be pushing up against the limits of that with a 128MB memory constraint. TASK DETAIL https://phabricator.wikimedia.org/T356402 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ArthurTaylor Cc: Lucas_Werkmeister_WMDE, Krinkle, hashar, Michael, Aklapper, ArthurTaylor, Danny_Benjafield_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, pdehaye, Nandana, Lahi, Gq86, Andrawaag, GoranSMilovanovic, QZanden, YULdigitalpreservation, KimKelting, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, MisterSynergy, thcipriani, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
