еще я бы юзал итераторы вроде .map() и .filter()
т.к. они ближе к бизнес логике работы с множествами, позволяют чайники (chain запуск при обработке) и лишь незначительно медленнее for
И регулярники, особенно .replace() потому что второй аргумент у нее - запуск функции
Т.е. чаще всего можно сразу провести операцию над найденным паттерном. Это здорово экономит логику (например, можно весь формато-логический контроль и конвертер в объекты уложить в один регулярник). Чайник дает продолжать обработку строки, но можно задекорировать на множества
Сорян за антипатерны )
По логике я бы отделил формализатор текста в объекты от подготовительных операций вроде сортировки интервалов и БЛ пересечений
Т. е. сначала "9:00-21:00? GM" в {begin:..., end:..., gm:true, player:...}, потом .sort(playersRanges), потом intersection
Ну и если цель выдать интервалы по дням, например, или с заданным кол-вом пересечений, то сортировка тут не сильно нужна, достаточно знать "сетку", а она может быть " построена" на первичном ФЛК прогоне. Сортировка очень дорогая операция, а здесь пахнет нахождением решения за 1 прогон. Можно подвинуть сортировку ближе к выводу, когда обьем данных снизится
Кстати, надо не забывать . sort((a, b)=>a-b)
Иначе [9, 8, 12, 1, 33, 21]. sort()
даст [1, 12, 21, 33, 8, 9]
хотя для дат и текстов это не важно
О, спасибо. Попробую переписать так, чтобы сортировку отодвигать на самый конец. Но там сортировать-то особо нечего. Там большая проблема только вызов самой кастомной функции с сервера Google. То есть сама сортировка, насколько я понимаю, проходит быстро. В массивах данных не больше 100.
