Сообщение Re[37]: Java vs C# vs C++ от 09.10.2015 21:06
Изменено 09.10.2015 21:10 Evgeny.Panasyuk
Здравствуйте, ·, Вы писали:
dot>>>ну например List<MyObj>
EP>>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
dot>Ничего, и не такое жевал.
Так в off-heap тогда смысла мало
EP>>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.
dot>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?)
Круто — чё
EP>>3. Лишние индерекции внутри List никуда не делись.
dot>List будет с большим числом элементов, иначе смысла извращаться нет. А на фоне этого большого числа данных один индирект не будет заметен в микроскоп.
Это один индерект на каждый элемент, а не просто один индерект. Разница может быть на порядки
EP>>>>И кто и как создаст эти newMyObj?
dot>>>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
EP>>"в общем-то и вся разница по факту." — да?
EP>>Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
EP>>Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
dot>Берёт что? Код-то тривиальный.
Берёт описание структур и генерирует все необходимые комбинации класс-контейнер/алгоритм.
dot>Вместо
dot>
Тут вообще достаточно:
Зачем get/set?
dot>пишем
Та самая ручная нарезка на структуры:
dot>
Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
dot>>>ну например List<MyObj>
EP>>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
dot>Ничего, и не такое жевал.
Так в off-heap тогда смысла мало
EP>>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.
dot>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?)
Круто — чё
EP>>3. Лишние индерекции внутри List никуда не делись.
dot>List будет с большим числом элементов, иначе смысла извращаться нет. А на фоне этого большого числа данных один индирект не будет заметен в микроскоп.
Это один индерект на каждый элемент, а не просто один индерект. Разница может быть на порядки
EP>>>>И кто и как создаст эти newMyObj?
dot>>>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
EP>>"в общем-то и вся разница по факту." — да?
EP>>Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
EP>>Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
dot>Берёт что? Код-то тривиальный.
Берёт описание структур и генерирует все необходимые комбинации класс-контейнер/алгоритм.
dot>Вместо
dot>
dot>class BusinessData
dot>{
dot> private int a;
dot> private int b;
dot> int getA() {return a}
dot> int getB() {return b}
dot>}
dot>Тут вообще достаточно:
struct BusinessData
{
int a, b;
};Зачем get/set?
dot>пишем
Та самая ручная нарезка на структуры:
dot>
dot>class BusinessData
dot>{
dot> private Buffer buf;//замаплен например сразу на приходящий из сети блок байт или offheap хранилище или ещё чего.
dot> private int pos;
dot> int getA() {return buf.getInt(pos)}
dot> int getB() {return buf.getInt(pos+4)}
dot>}
dot>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
Re[37]: Java vs C# vs C++
Здравствуйте, ·, Вы писали:
dot>>>ну например List<MyObj>
EP>>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
dot>Ничего, и не такое жевал.
Так в off-heap тогда смысла мало
EP>>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.
dot>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
Круто — чё
EP>>3. Лишние индерекции внутри List никуда не делись.
dot>List будет с большим числом элементов, иначе смысла извращаться нет. А на фоне этого большого числа данных один индирект не будет заметен в микроскоп.
Это один индерект на каждый элемент, а не просто один индерект. Разница может быть на порядки
EP>>>>И кто и как создаст эти newMyObj?
dot>>>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
EP>>"в общем-то и вся разница по факту." — да?
EP>>Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
EP>>Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
dot>Берёт что? Код-то тривиальный.
Берёт описание структур и генерирует все необходимые комбинации класс-контейнер/алгоритм.
dot>Вместо
dot>
Тут вообще достаточно:
Зачем get/set?
dot>пишем
Та самая ручная нарезка на структуры:
dot>
Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>
dot>>>ну например List<MyObj>
EP>>1. На GC всё равно будет висеть граф множества объектов, пусть и меньшего размера.
dot>Ничего, и не такое жевал.
Так в off-heap тогда смысла мало
EP>>2. Теперь на этих ссылках будут висеть финализаторы, так? Для того чтобы знать когда очищать off-heap. То есть теперь ко всему прочему ещё и освобождение будет линейным.
dot>Можно и финализаторы, а можно и явно реализовать delete, как в плюсах. Какое освобождение сделаешь, такое и будет.
В итоге получаем и линейный обход живых, и линейных обход мёртвых, да ещё и второй аллокатор/деаллокатор (кстати какой?), и в довесок ещё расстрел памяти.
Круто — чё
EP>>3. Лишние индерекции внутри List никуда не делись.
dot>List будет с большим числом элементов, иначе смысла извращаться нет. А на фоне этого большого числа данных один индирект не будет заметен в микроскоп.
Это один индерект на каждый элемент, а не просто один индерект. Разница может быть на порядки
EP>>>>И кто и как создаст эти newMyObj?
dot>>>Программист напишет. Притом можно описывать, скажем, интерфейсы, а их имплементации генерить при запуске.
EP>>"в общем-то и вся разница по факту." — да?
EP>>Придётся расписывать/генерировать не только пользовательские классы, но и воплощения всех контейнеров/алгоритмов в которых они участвую — иначе тормоза.
EP>>Покажи какую-нибудь библиотеку/утилиту которая берёт всё это на себя.
dot>Берёт что? Код-то тривиальный.
Берёт описание структур и генерирует все необходимые комбинации класс-контейнер/алгоритм.
dot>Вместо
dot>
dot>class BusinessData
dot>{
dot> private int a;
dot> private int b;
dot> int getA() {return a}
dot> int getB() {return b}
dot>}
dot>Тут вообще достаточно:
struct BusinessData
{
int a, b;
};Зачем get/set?
dot>пишем
Та самая ручная нарезка на структуры:
dot>
dot>class BusinessData
dot>{
dot> private Buffer buf;//замаплен например сразу на приходящий из сети блок байт или offheap хранилище или ещё чего.
dot> private int pos;
dot> int getA() {return buf.getInt(pos)}
dot> int getB() {return buf.getInt(pos+4)}
dot>}
dot>Так это же не спасает от тех же лишних индерекций которые есть в List<BusinessData>