Немного не понимаю претензии. В статье с разбором того, как и из чего состоит экземпляр класса, чему я должен был уделить внимания больше? Я привел много информации, которая нужна, чтобы понять, что делает CLR при создании экземпляра, а так же, как можно воссоздать самим этот процесс. Далее уже на ваше усмотрения, где и как аллоцировать. Хоть кастомным аллокатором, хоть через new byte[], хоть по шагам разбирать код CLR и детально воссоздать их алгоритмы.
В Unity такой хак не сработает из-за специфики работы Mono и их GC. Как минимум, я не смог адаптировать пока что код под Unity. Зависит от нужд проекта. Есть и более разумные решения, как пуллинг, ECS и адекватный Unsafe код, чтобы делать проекты, для которых не хватает стандартных средств .NET.
Именно. Не стоит в продакшен продукте ломать правила и делать такой код. Все таки пара миллисекунд не стоит таких рисков. Если у вас и возникает проблемы с аллокацией классов - более чем уверен, что проблема в архитектуре вашего продукта и в том, что вы сами выбрали использование классов :)
Вопрос открытый. На мой взгляд, так как аллокация происходит вне управляемой кучи, GC не должен обращать на нее никакого внимания. Но так ли - я не могу гарантировать, необходимо еще более глубокое исследование, которое уже, как я считаю, имеет мало смысла, ибо какого-то большого смысла для разработки такой подход не имеет, и сомневаюсь, что окупиться разбор всего нативного кода CLR. Однако, кто знает, когда мне станет скучно и, быть может, у статьи будет продолжение с более глубокими ответами и примерами :D
На том, что аллокация экземпляров класса - очень сложный процесс, который сильно затратнее, чем создание структуры. Поэтому вывод простой и немногословный, так как вся статья об этом.
Для общего развития, чтобы понимать, с чем ты работаешь, хотя бы на один уровень ниже. Какое продакшен-применение можно найти для статьи, которая в самом начале говорит "давайте нарушим правила"?
Немного не понимаю претензии. В статье с разбором того, как и из чего состоит экземпляр класса, чему я должен был уделить внимания больше?
Я привел много информации, которая нужна, чтобы понять, что делает CLR при создании экземпляра, а так же, как можно воссоздать самим этот процесс.
Далее уже на ваше усмотрения, где и как аллоцировать. Хоть кастомным аллокатором, хоть через new byte[], хоть по шагам разбирать код CLR и детально воссоздать их алгоритмы.
Думаю над этим. Если смогу написать достаточно материала - обязательно опубликую :)
В Unity такой хак не сработает из-за специфики работы Mono и их GC. Как минимум, я не смог адаптировать пока что код под Unity. Зависит от нужд проекта. Есть и более разумные решения, как пуллинг, ECS и адекватный Unsafe код, чтобы делать проекты, для которых не хватает стандартных средств .NET.
Именно. Не стоит в продакшен продукте ломать правила и делать такой код. Все таки пара миллисекунд не стоит таких рисков. Если у вас и возникает проблемы с аллокацией классов - более чем уверен, что проблема в архитектуре вашего продукта и в том, что вы сами выбрали использование классов :)
Вопрос открытый. На мой взгляд, так как аллокация происходит вне управляемой кучи, GC не должен обращать на нее никакого внимания. Но так ли - я не могу гарантировать, необходимо еще более глубокое исследование, которое уже, как я считаю, имеет мало смысла, ибо какого-то большого смысла для разработки такой подход не имеет, и сомневаюсь, что окупиться разбор всего нативного кода CLR.
Однако, кто знает, когда мне станет скучно и, быть может, у статьи будет продолжение с более глубокими ответами и примерами :D
Интересное замечание, буду иметь в виду на будущее, благодарю.
На том, что аллокация экземпляров класса - очень сложный процесс, который сильно затратнее, чем создание структуры. Поэтому вывод простой и немногословный, так как вся статья об этом.
Для общего развития, чтобы понимать, с чем ты работаешь, хотя бы на один уровень ниже.
Какое продакшен-применение можно найти для статьи, которая в самом начале говорит "давайте нарушим правила"?