Алексей Уколов

Если поисковый запрос начинается с символа %, то индекс толком не используется.
Вам нужен либо fulltext index и соответствующий запрос, либо сторонний поисковый движок типа эластика или мантикоры

Или хотя бы перенести сайт с того утюга, на котором он хостится сейчас, на нормальный сервер. Потому что 10 секунд на перебор трех сотен тысяч строк - это запредельные какие-то цифры.

Никак он не может отслеживать изменения в файле, пока его не сохранят. В каком редакторе вы пишите? Отключите опцию автосохранение редактора. В самом ватчере, можно использовать параметр задержки

function watcher() {
  gulp.watch('./src/style.css', { delay: 500 }, styles);
}
// в данном случае будет задержка в полсекунды после сохранения файла.

Хайлоад это не какой-то особенный тип проекта, это все обычные проекты, но с объемом "туда-сюдирования" данных выше, чем тянул "прошлый сервер", когда проект был еще не хайлоад. В 90% случаев это выражается в росте количества запросов к бд, которая либо становится слаба по железу, либо вылазят косяки в запросах, написаных абы как, включая отсутствие индексов и кривую архитектуру.

Что делается для "хайлоадинга"?
1) Меняются сервера на помощнее, но это больше к админам обычно.
2) Выявляются узкие места, в подавляющем большинстве случаев это либо обращения к бд, либо работа со сторонними сервисами, а-ля АПИ фейсбука и все такое.

Как разгонять именно такие затыки 2 варианта - есть 3 пути:
1) Оптимизация. Все что возможно ускорить - ускоряется, находятся самые тормознутые запросы, прогоняются через explain, переписываются, тюнятся, индексируются до состояния максимальной производительности.
2) Кэширование. Обычно используют кей-валуе инмемори хранилища а-ля мемкеш и редис, и результаты запросов часто используемых, но не часто обновляемых данных пишутся в кэш. Время жизни настраивается в зависимости от необходимой актуализации. По идее на высоких нагрузках даже кэш с времением жизни 5-10 секунд может в разы снизить нагрузку на сервера.
3) Иногда стандартных средств и инструментов не достаточно, и нужно искать какие-то новые инструменты, например переходить на сфинкс, так как фултекстсерч не вывозит. Или большие объемы данных идут на запись, и стандартной пропускной способности бд уже не хватает и нужно что-то типа систем хранения логов, или наоборот, аналитические бд по типу кликхауса...

Короче - все то же самое что и в стандарте, только оттюнено и обмазано кэшами и инструментами чуть сложнее мускуля...

В контроллере COM-порта несколько регистров. Запись в них определённых значений меняет режим работы порта. Эти регистры адресуются от базового адреса контроллера.
_outp(COMBase+3,0x80); - Line Control Register (LCR). Установка старшего бита разрешает доступ к делителю.
_outp(COMBase,0x01); - установка младшего байта делителя (0x01 => 115200 tick/s).
_outp(COMBase+3,0x03); - отключение доступа к делителю и установка размера символа 8 бит, 1 стоп-бит, без контроля чётности.
_outp(COMBase+1,0x00); - Inerrupt Enable Register (IER), запрет всех прерываний.
_outp(COMBase+2,0xC7); - FIFO Control Register (FCR), разрешить буферы FIFO размером 14 байт и очистить их.
_inp(COMBase); - прочитать байт из буфера.
www.osdever.net/documents/CP_serial.pdf

Никак.
По умолчанию, без специальных ухищрений, javascript работает в одном потоке.
Пока цикл не завершится - вообще больше ничего не произойдёт, в т.ч. реакция на клик - страница тупо "зависает".

Если говорить про конкретный пример, то он просто бессмысленный, даже с точки зрения житейской логики.
Учитывая, что if ($isTestOrder) можно прочитать, как ЕСЛИ переменная не занимает памяти то проверка выглядит просто глупостью. "Если переменная не занимает памяти, то не передавать её. Так мы с экономим память!" Если переменная и так не занимает никакой памяти, то какого еще дополнительно выделения памяти она может потребовать?

Если говорить про передачу параметров вообще, то оба неправы, но тимлид ближе к истине и надо всегда следовать его рекомендации не экономить на пустом месте. А экономить только адресно, когда экономия очевидна и востребована.

В общем случае тут не будет никакой экономии, ни на спичках, ни без.

При передаче параметра внутрь метода под него выделяется дополнительная память

- это чушь и неправда.

При передаче в функцию параметра, который в принципе может занимать хоть какую-то осмысленную память (то есть не числа, не булева значения, и не null), память под него НЕ выделяется.

• Объекты изначально передаются по ссылке
  
• Строки и массивы - с использованием механизма copy-on-write. Что означает, что память будет выделяться только если переданное значение будет изменено в процессе обработки. А если оно будет только считываться, то дополнительной памяти занимать не будет
  

Для всех остальных типов, как было правильно сказано тимлидом - это будет экономия на спичках.

Программные ошибки, в т.ч. в парсерах и декодерах форматов, могут эксплуатироваться для взлома.
Вот (а также более простыми словами вот и вот) пример с конца 2021 года, когда iOS-устройство заражалось PDF-файлом, присланным в виде картинки через iMessage. От пользователя не требовалось открывать сообщение или «картинку», заражение происходило автоматически при поступлении входящего сообщения.