Теоретически? Возможна. Но надо помнить что она трудна, и не всегда овчинка стоит выделки.
Вот для примера: В клане порядка 100 человек. Какая часть из них пользуется модулем? Я подключал к модулю своего клана гугловскую статистику, получалось в среднем 20-40 заходов за день. Это меньше половины клана, если каждый заходит только один раз. А обычно один человек делает 2-3 обновления страницы.
И вот и выходит, допустим мы зверски переписываем код, добавляем кэширование, отказываемся от большинства кода похожего на ООП и т.д. и т.п. и в результате модуль потребляет максимум 15мб памяти, при пиковой нагрузке с обновлением данных. Но стоило ли такая титаническая работа этого или нет?
Не поймите меня неправильно, оптимизацию проводить стоит. И в фоне она немного происходит. Например я пересмотрел код, и переписал все count(*) в mysql запросах, что дало выигрыша около 2-3мб памяти при загрузке страницы. На общем фоне немного, но тоже приятно. Вот пока писал, вспомнил что хотел создать sql файл добавляющий индексы к таблицам, что еще чуть чуть должно уменьшить потребление памяти.
Дальше, например, стоит отказатся от include_once в коде, и использовать простые include. Пересмотреть функции использующие больше одного запроса к базе, как это было с get_last_roster. Попробовать объединить циклы обработки данных, дабы уменьшить их количество. В общем варианты есть.
Может даже ввести небольшое кэширование данных. Что бы данные записывались в файл, например в виде json, и пока не прошел период обновлния данных считывались оттуда, правда для этого придется переписать код, дабы убрать все мелкие запросы к базе, и сделать несколько больших, и дабы функции потом просто работали с этими данными, а не брали из базы что им необходимо. Так будет очень просто сделать подмену запросов к абзе получением кэшированных данных.
Ну и надо понимать, что все описанное тут - огромный кусок работы, который проще прошлепать языком описывая его чем сделать.
И не факт что все это даст результат. Модуль все таки работает с большим обьемом данных.