так у вас не сортировка и не разбиение на страницы тормозят, а поиск по регэкспу. который не индексируется. замените его на full-text search (tsvector и так далее) или действительно на какой-нибудь внешний индексатор, типа солра или сфинкса, переводите.
const arr = [].concat([1,23,23,21,1,23,41],[2,12,3,321,234,234,1,31,321,22,3],[12,32,53,1,3,12,3,2],[12,32,53,1,3,12,3,2]);
let set = new Set();
while(set.size < 6) set.add(arr[Math.random()*arr.length|0]);
[...set]
матчить регэкспами иерархические структуры довольно муторно, и далеко не каждый регэксповый движок рекурсивные регэкспы умеет. предполагаю что в вашем случае эти тэги post вложенными не бывают.
самый простой способ - это заматчить в два приёма: сначала простейшим регэкспом вытащить один блок с постом, а потом таким же примитивным регэкспом в вытащенной части найти первый подходящий атрибут.
по сравнению с одним хитрым регэкспом, который делает всё сразу, это и быстрее работать будет, и намного проще/понятнее для тех, кому этот код придётся поддерживать.
а если всё-таки нужен именно один регэксп, то он может выглядеть примерно так:
/<post id = x1>(?:.(?!\/post>))*?max=(.*?)>/s
разумеется это упрощённый пример, вам придётся ещё как минимум обрабатывать другие тэги и атрибуты, whitespaces и так далее. но вон то место, где нежадно матчится конструкция с noncapturing group в которой точка с negative lookahead - это наверное и есть то, о чём вы спрашивали.
поднять какой-нибудь continuous integration сервер. если многого не надо, то в принципе пойдёт любой: тот же jenkins или teamcity. кстати, у вас же гитлаб, в нём должен быть из коробки свой ci
приделать инпуту подстройку размера под введённое значение (как это сделать хорошо - другой вопрос), убрать у него рамку и дописать текст после него. рамку добавить вокруг всей конструкции.
вы пытаетесь логику связать с повторяющейся разметкой. это фундаментально неправильный подход.
для такой задачи достаточно иметь разметку для одного вопроса с ответами без текста (шаблон), а текст всех вопросов и ответов иметь как данные в скрипте.
текст текущего вопроса и ответов на него выводить в нужные места разметки, при выборе ответа переходить к следующему.
то есть данные отдельно, отображение отдельно. а там и до mvc недалеко.
если позволяет архитектура, можно хранить жсон в сжатом гзипом виде и отдавать клиенту не распаковывая. самый оптимальный вариант из всех - экономит и дисковый ввод/вывод, и сетевой, и место в кэше.
если не позволяет, и всё равно не влазит, то можно в mongofs затолкать.
настроить хттп заголовки кэширования при отдаче содержимого страниц и спокойно запрашивать каждый раз. браузеры не вчера кэшировать научились, они это делают куда эффективнее чем вы руками. их нужно только правильно проинструктировать.
у ёкселя есть excel power query ("редактор запросов" по-русски), как раз для таких вещей.
а если сейчас вы проверяете строки в одной таблице поиском по второй, можно сильно ускорить процесс отсортировав вторую таблицу по этой колонке, и используя поиск значения с третьим параметром (интервальный поиск) и дополнительной проверкой на совпадение потом.
графики с большим количеством данных вообще трудно делать, при каком-то размере датасета любой подход перестаёт работать.
конкретно насчёт скорости простой отрисовки, главное - не перекрашивать одни и те же пикселы много раз. если у вас, конечно, не 30 тысяч пикселов в ширину график, то на одну колонку пикселов у вас рисуется много отсчётов. поэтому можно отобрать данные, которые попадают в эту группу, взять из них минимум и максимум (если диапазон не касается прошлого - растянуть до его границы) и отрисовать одной линией.
совсем давно пользовались распорками в ячейках таблиц из однопиксельных прозрачных гифов. страшно подумать сколько файлов spacer.gif до сих пор лежит в интернете.
во времена ie6, когда мы уже заморачивались на семантику и стеснялись верстать таблицами, применяли ещё метод эмуляции min-width широкими бордерами по бокам враппера и компенсирующим их отрицательным маржином внутреннего дива.
битовые операции (и операции с подстроками) по-человечески не индексируются.
по булевым полям индес тоже низкоселективный, но если галочек в конкретном запросе сильно меньше чем галочек всего, то польза будет.
так что лучше разложить флажки по отдельным полям.
если всё плохо, и сгенерировать настоящий xlsx каким-нить POI на сервере никак нельзя, то можно по-колхозному сгенерировать html таблицу и отдать её файлом с ёкселевским расширением и Content-Type: application/vnd.ms-excel
ёксель будет ругаться, но откроет и даже какое-то оформление попытается воспроизвести, если оно инлайновыми стилями задано. ещё можно пытаться ёкселевские атрибуты ячейкам добавлять, подсмотрев их в том хтмл, который сам ёксель выгружает.
это, конечно, не полноценное решение, но зато тривиально реализуемое чисто на клиенте.