VoidVolker

Хочется изучить CI/CD и Kubernetes, чтобы приложения сразу деплоились в k8s.

Если только изучить, то дешевле всего будет взять vps + миникуб/любой другой однонодовый дистрибутив.
Для изучения тебе не нужен полноценный кластер с несколькими физическими нодами.

Нет никакого "лучше". Есть только то, для чего они предназначены и об этом подробно говорится в документации.

0. Каждый из этих модификаторов имеет разные смыслы в зависимости от контекста.
1. ref struct - запрещает боксить структуру и вообще как-либо иначе заносить в кучу.
2. in (в женериках) - обозначает, что параметр контрвариантный (загугли)
3. out (в женериках) - обозначает, что параметр инвариантный (тоже загугли)
4. in/ref/out как модификатор аргументов методов - указывают, что передаваться будет ссылка (например на переменную).
in - запрещает модификацию. out - обязывает инициализировать перед завершением метода. ref - никчему не обязывает.

Из очевидных, но не ограничивающих сценариев использования (п4):
1. in - для передачи больших структур, чтобы они не копировались.
2. out - для TryParse
3. ref - для Swap
4. Ещё их всех можно использовать в P/Invoke для того же самого. Всякие нативные методы достаточно часто работают со ссылками.

если я перейду на визуализатор pixi то будет ли существенное повышение производительности?

Matter использует 2D канвас (если мы говорим про их стандартный рендерер). Pixi - WebGL. Ваш вопрос получается не про Pixi, как библиотеку, а про разницу технологий.

Когда-то было такое время, что 2D-канвас рендерился полностью на CPU, и тогда разница между ним и WebGL была в первую очередь обусловлена этим фактом. WebGL - это более низкоуровневый интерфейс с доступом к видеокарте. Много ядер, процессы хорошо распараллеливаются, при наличии прямых рук и понимания основ компьютерной графики все рендерится быстрее. Но в наше время и 2D-канвасы ускоряются видеокартой. Если очень грубо говорить, то сейчас 2D канвас - это тот же GL-канвас, но с более высокоуровневой обвязкой сверху. Чисто для удобства. Можно сказать, что разница в алгоритмах самого рендеринга с годами сводится к нулю, остается лишь разница в обвязке. Изначальная высокоуровневая структура вокруг 2D-канваса с кучей условно ненужного в конкретных случаях функционала не оптимизируются так эффективно, как бы нам хотелось. Она не умеет предсказывать наши намерения. Из-за этого переход от 2D к WebGL может дать прирост производительности. Но не столько за счет самого рендеринга, сколько за счет более умного переиспользования ресурсов и избавления от всех ненужных в конкретных случаях операций. Так что в целом идея взять двумерный рендерер на WebGL и делать в нем только то, что требуется, и ничего лишнего - все еще хорошая. Плюс у него будет сразу задел на использование своих кастомных шейдеров, что открывает целый мир визуальных эффектов, неподвластных 2D-канвасу.

Но не стоит ждать чуда - уменьшение времени обработки одного среднестатистического игрового кадра в 2-3 раза можно будет считать хорошим результатом. Тесты, в которых люди меряют разницу в десятки раз, обычно завязаны на какие-то узкие случаи с переиспользованием ресурсов. Далеко не факт, что это будет ваш случай. Так что если у вас там что-то конкретно тормозит - может быть будет больше пользы от оптимизации узких мест в текущей логике, чем от машинального переписывания всего на других инструментах.

1. Это для работы с COM
2. Если почитаешь подробную документацию на английском на prservesig, то всё поймёшь.
COM методы возвращают hresult, который сообщает об успехе или ошибке.
Проведение по умолчанию - всё что не успех преобразовывать в исключение.

Preservesig сохраняет оригинальную сигнатуру и отдаёт hresult как есть, что может быть полезно, если ты хочешь как-то сам его проверить и обработать без выбрасывания исключений

Прошу рассказать принцип работы данной программы,

openserver - это одна из множества сборок ПО для разворачивания локального WEB-сервера. См WAMP.

И принцип их простой - они состоят из комманд для управления этим ПО и конфигурационных файлов. И на всё это навешен GUI

Ставите и настраиваете сторонний бэкаппер, делаете расписание с сохранением с несистемную папку на другой диск, а лучше всего в облако.
Вуаля.

const dateTimeFormatter = new Intl.DateTimeFormat(
  'sv-SE',
  {
    dateStyle: 'short',
    timeStyle: 'medium',
  },
);
console.log(dateTimeFormatter.format(new Date()));
// "2024-01-29 09:11:47" 
console.log(dateTimeFormatter.resolvedOptions().timeZone);
// "Europe/Moscow"

https://aliexpress.ru/item/1005003725851528.html
https://aliexpress.ru/item/4000113520641.html
https://aliexpress.ru/item/1005001473821330.html

https://aliexpress.ru/item/1005006256867305.html
https://aliexpress.ru/item/1005002037057062.html
https://aliexpress.ru/item/1005002924235606.html

1. Вебсокеты - это сложновато.
2. Вебсокеты на PHP - вдвойне сложно. Проблема в том, что PHP задуман как скриптовый язык, т.е. скрипт выполняется заканчивает свою работу. А вебсокет - это постоянное соединение, т.е нам надо, чтобы программа постоянно крутилась в фоне. Вебсокеты можно реализовать на PHP, но, как персонально мне кажется, проще будет выучить Go )) , или же, как в ответе уважаемого Артём , сделать сервер на ноде.
3. Если ваш чат не такой супер-функциональный, как чат в мессенджерах, то вместо вебсокетов можно обойтись SSE (Server Sent Events). SSE так же требует постоянного соединения, но всё работает через HTTP, и это ну прямо намного проще. Единственный недостаток - это то, что SSE работает только в одну сторону: от сервера в браузер. Т.е. запросы из браузера можно получать обычным POST запросом, а отдавать обратно информацию уже через SSE.

С SSE есть два пути:
1. Написать сервер самому, используя какую-то простую библиотеку вроде этой https://github.com/hhxsv5/php-sse
2. Но я бы сделал ещё проще. Есть такой великолепный проект под названием Mercure https://mercure.rocks
Это отдельный сервис на Go, задача которого как раз поддерживать SSE соединение и отправлять сообщения в браузеры. Сервис сидит в фоне, а браузеры подписываются на события через EventSource буквально в три строчки, как описано тут https://mercure.rocks/docs/getting-started
Прелесть этого в том, что для того, чтобы отправить сообщение всем браузерам из кода на PHP, вам надо просто сделать обычный POST запрос на специальный адрес этого сервиса Mercure с телом самого сообщения и его id. Т.е. вам не надо делать никаких долгоживущих процессов на PHP, всё будет работать как раньше.

Т.е. подытожим:
- Браузеры пользователей подписываются на события в Mercure
- Пользователь 1 отправляет текстовое сообщение обычным POST запросом на обычный PHP сайт.
- PHP сайт получает этот POST запрос, определяет, что его надо отправить Пользователю 2, и отправляет соответствующее сообщение обычным POST запросом в сервис Mercure
- Mercure отправляет сообщение Пользователю 2 через SSE, на которые он подписан.
- Сообщение появляется у него на страничке