1) Зачем вам вообще массив чисел?
2) Паузить основной поток - так себе идея, ИМХО
3) Есть бесконечный цикл без всяких возможностей его прервать.
4) Куча лишних переносов строк, левые пробелы, нет пробела между параметрами... В общем кодстайл так себе.
1) Самое примитивное - пресеты цветов. И выбирать уже из массива пресетов.
2) Попробовать использовать HSL вместо RGB. Во первых "похожие" цвета в нем легче детектить, во вторых легче получить более разные цвета - просто параметр H генерить с каким то шагом, а не весь диапазон от 0 до 1.
А чего тогда сразу не статическим его сделать?
Синглтон - не единственный метод взаимодействия классов (и вообще это не про взаимодействие, ну да ладно, суть понятно). Почитайте про инъекцию зависимостей (без фреймворков), например.
В том же юнити можно до кучи использовать и SerializeField, и GetComponent, и ненавинсый FindObjectOfType,
Берете все данные, которые вам нужно сохранить, загоняете в json/xml, и сохраняете в PlayerPrefs как строку.
Для оптимизации можете подробить на логические элементы.
В случае конкретно этих двух - производительности ЯП нет. Есть производительность среды, которая выполняет код - JIT и вот это все. И они есть разные под эти языки.
Ели вы возьмете вообще Unity, в котором тоже сишарп - то там внезапно вы получите совсем другой результат - потому что от сишарпа там может ничего и не остаться. Это пример.
Потому что удаленный сервер вас послал нафиг. Вариантов много:
1) Нет интернетов на компе/лочит фаервол
2) Неправильные креденшиалы/адрес сервера
3) На самом сервере не разрешено подключение по SMTP-протоколу.
Совет - взять любой заведомо рабочий клиент (типа the Bat!), и настроить подключение в нем. Когда будет настроено - проанализировать шаги и отличия.
Если вы уж так интересуетесь оптимизацией, то должны понимать, что сравнение двух величин может выполняться дольше, чем мат.операция.
В вашей формуле - используется max и min. В классической формуле квадратичного расстояния - только умножение и сложение. Что ИМХО быстрее. К тому же в самой доке написано - бонус в том, что НЕ ИСПОЛЬЗУЕТСЯ корень (да, корень - дорогая операция).
И - если я правильно прочитал формулу - вам все равно нужны длины векторов. Что опять таки корень и все такое.
В общем - не уверен что это даст прирост, не даст погрешности (вроде в доке что то об этом есть). И, если хотите в оптимизации - учите математику.
1) Код в тег "код"!
2) Где у вас вне рамок? В выводе консоли? И вне каких рамок? Если речь про вывод консоли и рамки (1-5) - то все логично. У вас i максимум равен 4, а потом вы к нему прибавляете случайное число, которое может быть равно от 1 до 5.
Ну т.е. то, что юнити в итоге транслирует c# в c++ вас не смущает? ;-)
По факту. При использовании движка важность языка в контексте перфоманса уже отошла с первого плана. Смотрите на поддерживаемые платформы, на рендер-пайплайн, на внутренние оптимизации.
continue завершает текущую итерацию цикла.
Т.е. если i%2 !=0 - то все дальнейшие действия в цикле игнорируются, и он перейдет на след. итерацию.
Код с аналогичным действием, но без continue:
for(int i = 0; i<100; i++)
{
if (i % 2 == 0) //инвертированное условие!
{
Console.WriteLine(i);
}
}