Object Pool, Пул объектов, Паттерны на практике, Unity, C# 

Спасибо, а я кажется догадался, кто тот Вячеслав кто мне донатит :D

@@sergeykazantsev1655 это мелочь, хороший урок бесценен )

Хорошая идея, возьму на вооружение)

Поздравляю с защитой курсовой!) Вообще, джунов давно не набираем, команда устоялась, так что актуальную ситуацию не знаю. Мне кажется реактивное программирование стоит выше обычных требований к джуну, но так как рынок переполнен кандидатами, я бы сказал что будет здорово понимать концепцию реактивных свойств, дата биндинга, и "что-то слышать про uniRx". Вы вроде видели видео про MVVM там эта тема косвенно упоминается.

Это очень сложный вопрос, надо индивидуально смотреть) Общий совет - надо лезть в профайлер и смотреть что больше всего нагружает CPU

@@sergeykazantsev1655 Понял, спасибо)

Привет! Спасибо! Могу ошибаться, но с моей точки зрения под опытом оптимизации подразумевается опыт работы с профайлером и понимание какие вещи могут нагружать игру. В зависимости от того что именно вы делаете в игре: у вас будет страдать или CPU(много сложной физики, коллайдеров, многослойного взаимодействия между объектами или много Instantiate, Destroy или много кода в Update-ах) или GPU(Мощный визуал, сложные шейдеры, текстурки, много риалтаймового света, возможно тяжёлые канвасы тоже видюху грузят, но может и CPU уже не помню) или RAM ( много объектов на сцене с большим количеством полигонов, огромные миры) То есть простым языком, надо понимать что в вашем проекте может сильно нагрузить вашу игру. Обычно достаточно соблюдать базовые правила оптимизации, чекать профайлер, количество draw call-ов и batch-ей и станет понятно где проблема

@@sergeykazantsev1655 понял, спасибо!

Полагаю что дело в асимптотике, вставка элемента в коллекцию свободных элементов и извлечение осуществляется за о(1) В моей реализации и свободные и занятые элементы находятся в одном списке и там асимптотика дороже: о(n)

@@sergeykazantsev1655 то есть в теории, если бы вы использовали лист для свободных элементов и просто брали бы оттуда элемент под 0 индексом, то стоимость была бы одинаковая?

Нет. По алгоритму от юнити нам нужно не только брать элемент под 0 индексом, но и удалять его из коллекции. Вставка и удаление в стеке верхнего элемента занимает o(1) Вставка и удаление в листе верхнего(индекс 0) элемента занимает o(n) Тут скорее можно поизвращаться и вставлять и удалять элементы в листе из последнего элемента, так как вставка и удаление последнего элемента так же требует o(1). Но не следует забывать о Capacity в листе и в случае если лист переполняется, то он пересоздаётся с объёмом в 2 раза больше предыдущего и таким образом мы тратим o(n) на копирование из старого маленького массива в новый расширенный

Спасибо за мнение! Объясню свою позицию. В сообществе программистов есть немалая доля перфекционистов, которые помешаны на ООП, оптимальности и идеальности каждой строчки кода. Лично видел синьора с огромным опытом который не мог написать за месяц раннер типа сабвей сёрфера, ибо завяз в сложных абстракциях. Несмотря на то, что на моём канале мало подписчиков и просмотров, на мой канал уже залетают мамкины перфекционисты которые начинают меня критиковать, один такой упорно доказывал что сервис локатор бесполезный и вредный паттерн и его нельзя ни при каких обстоятельствах использовать. Словами про "колхозника" я говорю о том, что код может нарушать какие-то ООП принципы, этот код можно написать лучше и качественнее. Тем не менее этот код выполняет поставленную задачу, не создаёт проблем производительности и его довольно удобно расширять. Так что данный код приемлем с моей точки зрения. И этими вставками я пытаюсь показать новичкам мысль, что даже хорошо написанный и работающий код может иметь слабости, неоптимизированные места, недоработки и тд. И это норма жизни, с которой скорее всего каждому придётся столкнуться.

@@sergeykazantsev1655 Ахахаха, ну да, я тебя понял, спасибо за ответ. Тогда Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще? XD