Ссылочные типы и верх производительности памяти

[KoteKotovK]

Приветствую! Основной вопрос заключается в работе языка C# и его реализацией ссылочных типов. Представим у меня есть ссылочный тип TestClass с N количеством переменных и есть другой класс в котором присутствует не назначенная (не сериализированная) переменная типа TestClass. Сколько весит именно переменная с ссылкой на элемент кучи? Это же ведь некая ссылка на ячейку памяти? И основная суть вопроса такова, что если у меня имеется игра текстовый квест, где определённо у меня используются символы и слова. Имеет ли смысл каждому слову выдавать ссылку, в особенности повторяющимся словам, с целью использования меньшего кол-ва памяти? Или имеет ли ещё больше смысла выдать ссылки всем используемым символам? Представим что у нас есть слово "Яблоко", которое весит 12 байт и информация строкового массива где-то 12 байт, в сумме 24 байта. При каждом повторении словам мы будем занимать 24 байта, но ведь смысла в этом мало, ведь зачем нам индивидуальная переменная для этого слова? Разве не будет более производительней ссылаться на это слово? Или здесь я столкнусь с проблемами реализации памяти кучи? Какие вообще проблемы будут меня преследовать, если я буду использовать чаще ссылочные типы, нежели структуры?

[Anonymyx]

Ссылка сама по себе весит 4 байта на 32х битных машинах и 8 на 64х, это есть в документации msdn. Да, это указатель на первую ячейку в памяти где начинается область объекта.
Насчет строк... если у вас эти слова хранятся в коде как строковые литералы, т.е. забиты прямо в код, то есть такая штука как интернирование строк, она встроенная. Это когда на этапе компиляции все уникальные строки запихивается в пул строк, а дальше когда мы используем одну из наших строк, вместо создания новой возвращается сслыка на строку из пула строк.
Но там есть свои ньюансы, погуглите про это.

[Tolking]

У тебя уже с психикой не очень, раз задумываешься о таком, а если начнешь реализовывать можешь вообще с катушек съехать! Но уж если не отпустит через некоторое время, то переходи на ассемблер... Если поймешь, что асм не дает желаемого результата и биты в регистрах используются не оптимально, обязательно сходи к психиатру!

[KoteKotovK]

У тебя уже с психикой не очень, раз задумываешься о таком, а если начнешь реализовывать можешь вообще с катушек съехать! Но уж если не отпустит через некоторое время, то переходи на ассемблер... Если поймешь, что асм не дает желаемого результата и биты в регистрах используются не оптимально, обязательно сходи к психиатру!

На самом деле, я заметил что начинаю задавать много вопросов по целесообразности работы в C# и Unity3D как таковом, но больше ни в чем опыта не имею, поэтому выбирать пока что не приходится. Суть в том, что хочется сделать удобную архитектуру для игры, которую проще дополнять и изменять, некая модульная парадигма. Что бы не было проблем с удалением какой-то части игры, или наоборот добавлении чего-то нового, что может внести некие изменения в старое, но ООП будто сам по себе ограничивает меня рамками моей человеческой уверенности и продуманности. Я уже сталкивался с проблемами переписывания система и иногда невероятной нечитабельности кода, так что пытаюсь найти более правильные ориентиры, тот же ECS больше походит на более продуманную и удобную систему, ещё и более производительную для многопоточных процессоров, как я понял, но проблема в том, что ECS сейчас сильно изменчив в самом Unity, потому что его только разрабатывают, а для самопродумывания всего этого, нужно обладать бОльшим количеством знаний, нежели у меня есть. Просто кажется, что можно намного проще разрабатывать большие игры, но в чём именно проблема - фиг его знает. Я будто бы загнан в угол.

[KoteKotovK]

Ссылка сама по себе весит 4 байта на 32х битных машинах и 8 на 64х, это есть в документации msdn. Да, это указатель на первую ячейку в памяти где начинается область объекта.
Насчет строк... если у вас эти слова хранятся в коде как строковые литералы, т.е. забиты прямо в код, то есть такая штука как интернирование строк, она встроенная. Это когда на этапе компиляции все уникальные строки запихивается в пул строк, а дальше когда мы используем одну из наших строк, вместо создания новой возвращается сслыка на строку из пула строк.
Но там есть свои ньюансы, погуглите про это.

Спасибо за наставление, изучу что такое интернирование строк. Кстати, сама суть "пула строк", это примерно то, чего я и добивался, но из-за незнания начал создавать велосипед.

[Anonymyx]

Ну не знаю, если вы считаете что ООП вас как-то ограничивает, то, ИМХО, у вас недостаточное понимание/опыта в применении ООП.
ООП как раз таки дает хорошую возможность создания гибкой и делегированной системы, а насколько это все хорошо сделано, зависит от умения разработчика мыслить абстрактно и исполнять заветы ООП, особенно касаемо инкапсуляции.
Хз, слишком обобщенно все, трудно написать что-то конкретное
Я тоже через такое проходил, все приходит с опытом.
Не думайте что я там какой-то гуру программист, просто высказываю мнение.

[IDoNotExist]

На самом деле, я заметил что начинаю задавать много вопросов по целесообразности работы в C# и Unity3D как таковом, но больше ни в чем опыта не имею, поэтому выбирать пока что не приходится. Суть в том, что хочется сделать удобную архитектуру для игры, которую проще дополнять и изменять, некая модульная парадигма. Что бы не было проблем с удалением какой-то части игры, или наоборот добавлении чего-то нового, что может внести некие изменения в старое, но ООП будто сам по себе ограничивает меня рамками моей человеческой уверенности и продуманности. Я уже сталкивался с проблемами переписывания система и иногда невероятной нечитабельности кода, так что пытаюсь найти более правильные ориентиры, тот же ECS больше походит на более продуманную и удобную систему, ещё и более производительную для многопоточных процессоров, как я понял, но проблема в том, что ECS сейчас сильно изменчив в самом Unity, потому что его только разрабатывают, а для самопродумывания всего этого, нужно обладать бОльшим количеством знаний, нежели у меня есть. Просто кажется, что можно намного проще разрабатывать большие игры, но в чём именно проблема - фиг его знает. Я будто бы загнан в угол.

Все эти твои проблемы решаются очень просто: http://macode.ru/

Я уже сталкивался с проблемами переписывания система и иногда невероятной нечитабельности кода, так что пытаюсь найти более правильные ориентиры

Переписывание кода, это есть крайне правильное и полезное занятие, а если ты ищешь ориентиры в ECS при малом опыте, то это не правильные ориентиры, для начала ИМХО надо научиться думать в ООП ключе.

[KoteKotovK]

Я, насколько мне самому известно, умею думать и работать в рамках ООП, но проблема заключается на моменте проектирования/продумывания. Переписывание кода нормально, если ты допустил критическую логическую ошибку в самом написании кода, переписав код ты на практике закрепишь суть ошибки и как её не допустить в будущем, но достаточно сложно не допускать ошибки при проектировании, когда ты сам не знаешь чего именно хочешь, полная неуверенность, она есть везде, окромя маленьких проектов. А ведь такие ошибки случаются уже и во время производства игр, и даже у таких мастодонтов индустрии как Rocstar Games, когда какие-то механики на бумаге, в момент пред производства, выглядят классно, а на деле достаточно унылы, особенно сложно этот баланс найти в реализме, который я и пытаюсь продумать у себя в проекте. Я бы заикнулся про модульность в C#, но мне скорее всего предложат шаблоны проектирования, которые по сути должны были стать для меня панацеей, но на деле сложность появилась не в проектировании, а в написании кода, он стал слишком абстрактным, сложнее стало в нем ориентироваться. Сложно создавать такие архитектуры для таких игр, которых не существует ни где, кроме как у меня в голове. Я даже не понимаю как работает архитектура движка на котором работаю, могу только догадываться. Компонентная система вообще загадка. Например, довольно странно выглядит компонент скрипта с описанными переменными и функциями, которые существуют, как кажется, для всех одинаковых экземпляров, выглядит так будто бы порождаем кучу одинаковых сущностей функций и переменных, хотя могли бы так не делать, как в ECS, но вполне реально, что это просто так "выглядит", но работает иначе, например после компиляции.

[KoteKotovK]

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

[IDoNotExist]

В таком случае, если мы отказались от еды, нам придется подтереть везде реализацию связанную с этим,

Зачем?

[KoteKotovK]

В таком случае, если мы отказались от еды, нам придется подтереть везде реализацию связанную с этим,

Зачем?

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

[IDoNotExist]

Представьте, что это скорее некий конструктор

с кодом вы нигде не сталкиваетесь

https://assetstore.unity.com/packages/tools/visual-scripting/playmaker-368

[1max1]

Ох как же мне это знакомо... Рефакторинг кода отнимает наверное большую часть моего времени, чем его написания, в целом мой подход выглядит так:
Написал говнокод -> проверил работоспособность -> если работает, делаем оптимизацию, если нет -> начинаем заново))
По поводу строк, это ты конечно слишком запарился, в современных компах считать байтами уже не в моде. А так, в целом вопрос об архитектуре проекта очень актуален и ответ на вопрос "Как будет лучше, так или эдак?" приходит с опытом, нужно постоянно писать код, постоянно проектировать и наступать на грабли, а потом уже будешь четко представлять всю картину. Если бы ты знал как я иногда парюсь даже над названиями переменных)) Не то что над реализацией...
Про ECS. Вообще система достаточно удобная, как по мне, последнее время только на ней всё и делаю, правда я накидал свою ECS с блекджеком и костылями, но суть остается та же. Адекватное совмещение с монобехами дает вполне приемлемый результат для небольшой игрушки, ну и код получается не такой раскиданный.

[KoteKotovK]

Представьте, что это скорее некий конструктор

с кодом вы нигде не сталкиваетесь

https://assetstore.unity.com/packages/tools/visual-scripting/playmaker-368

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

[KoteKotovK]

Написал говнокод -> проверил работоспособность -> если работает, делаем оптимизацию, если нет -> начинаем заново))

В точку!)