Хотя нет. Int это 2 гига.

ну если ток ты не шипилев

Хотя нет. Int это 2 гига.

я поэтому и написал, имеет смысл если тебе нужна работа с большими файлами, 2гб эт мало

Aleksey в твоем случае есть смысл избавится от gc, как примеру сделал это netty

чтоб не было пауз

Мне и так понятно как избавляться от gc. Вопрос только в том где хранить байты. Это должен быть либо обычный байтбуфер, либо direct.

Ты прямо очень влюблён в нетти, постоянно про него пишешь, как будто сначала был нетти, а только потом хранимки на постгрессе

от gc никак не избавиться, но тебе можно будет юзать какой-нибуль parallelgc сборщик, и делать сборки редко

от gc никак не избавиться, но тебе можно будет юзать какой-нибуль parallelgc сборщик, и делать сборки редко

Это не подходит. Хорошая библиотека должна выдавать приемлимый результат без тюнинга.

опять же смотря что больше надо - меньше напряга для gc или меньше затраты времени на выделение в куче

Это не подходит. Хорошая библиотека должна выдавать приемлимый результат без тюнинга.

ДООООО

это сынок фантастика)

опять же смотря что больше надо - меньше напряга для gc или меньше затраты времени на выделение в куче

Выделение в куче быстрые (я вчера в Шипилева спрашивал), дайрект выделяется немного медленнее чем обычный. В моем случае это вообще не принципиально.

кстати почему никто не спросил, почему я посоветовал pargc

Потому что ты любишь давать советы о которых никто не просил

я советы не давал, я лишь спросил, почему Алексей решил делать байт буферы

@gurinderu кстати, я не сноб, но вот тебе http://tsya.ru

кстати почему никто не спросил, почему я посоветовал pargc

потому что он обеспечивает нормальный thrpt в отличие от того же g1

потому что он обеспечивает нормальный thrpt в отличие от того же g1

дай пятюню бро)

кстати почему никто не спросил, почему я посоветовал pargc

Шаблоны в Королеве это бутылочное горлышко. Это было понятно с самого начала. Ни один GC не спасет от 10000 аллокаций на каждый чих.

Выделение в куче быстрые (я вчера в Шипилева спрашивал), дайрект выделяется немного медленнее чем обычный. В моем случае это вообще не принципиально.

Тогда всё опять же зависит от того, насколько у тебя будет много этих объектов и насколько большие, если так, то может и есть смысл в оффхипе

Шаблоны в Королеве это бутылочное горлышко. Это было понятно с самого начала. Ни один GC не спасет от 10000 аллокаций на каждый чих.

получается у тебя будет на каждого клиента создаваться все в байтбуфере

тогда эт имеет смысл

дай пятюню бро)

доклады Шипилева?

доклады Шипилева?

ну про мутаторы я и без него знал) ну да ладно, все равно они полезные

@gurinderu кстати, я не сноб, но вот тебе http://tsya.ru

ты даешь советы, о которых тебя никто не просил

@gurinderu у меня отличный учитель

@fomkin но мне кажется эт будет очень сложным решением

токсичненько

Сорвалось дол

Тогда всё опять же зависит от того, насколько у тебя будет много этих объектов и насколько большие, если так, то может и есть смысл в оффхипе

Это и хочется понять. По идее дайрект должен начинать работать нормально от 4k (дефолтный размер страницы). С бенчмарками @gurinderu что-то не так, потому что DirectBB должен быстрее (достаточно почитать код).

@fomkin но мне кажется эт будет очень сложным решением

А что делать? Вот у меня есть шаблоны которые не делают аллокаций. Первый шаг сделан. Теперь надо сделать что бы дифы рассчитывалсь без выделений.

Это и хочется понять. По идее дайрект должен начинать работать нормально от 4k (дефолтный размер страницы). С бенчмарками @gurinderu что-то не так, потому что DirectBB должен быстрее (достаточно почитать код).

да с чего ты эт взял то?) наверняка он какой-нибудь malloc внутри себя юзает (над глянуть(

А что делать? Вот у меня есть шаблоны которые не делают аллокаций. Первый шаг сделан. Теперь надо сделать что бы дифы рассчитывалсь без выделений.

дык ты бы написал сперва простой вариант, а потом оффхип

А что делать? Вот у меня есть шаблоны которые не делают аллокаций. Первый шаг сделан. Теперь надо сделать что бы дифы рассчитывалсь без выделений.

ты пошел быстро вверх по кривой Шипилева))

да с чего ты эт взял то?) наверняка он какой-нибудь malloc внутри себя юзает (над глянуть(

Обычный использует обычный array[]. Дайрект юзает маллок, совершенно верно.

ну дык вот и ответ, malloc не такой быстрый

ты пошел быстро вверх по кривой Шипилева))

Просто у меня из за алокаций в шаблонах действительно все плохо. 100 юзеров на ноду это вообще не дело.

правда эт на put и get не должно влиять

ну дык вот и ответ, malloc не такой быстрый

Он делается ОДИН РАЗ!

ну типо нативные вызовы, оверхед и всё такое, вопрос будет ли этот оверхед большим по сравнению с затратами ресурсов на gc

Он делается ОДИН РАЗ!

угу

ну типо нативные вызовы, оверхед и всё такое, вопрос будет ли этот оверхед большим по сравнению с затратами ресурсов на gc

Обращения к выделенной памяти это не сисколы. После маллока процесс может свободно ходить по выделенным страницам.

в общем над глянуть код

Обращения к выделенной памяти это не сисколы. После маллока процесс может свободно ходить по выделенным страницам.

после - да, конечно, я про первоначальное выделение говорил

возможно там какие т проверки есть

В общем, @fomkin тебе нужно оба варианта попробовать, на самом деле замена одного на другое - процесс нехитрый же

direct то тож проверки разные делает

после - да, конечно, я про первоначальное выделение говорил

Оно не имеет значения. Одно одно на каждую сессию в момент подключения. 300 микросекунд на минутную сессию в случае директа против 100 микросекунд на минутную сессию в случае обычного буфера.

direct то тож проверки разные делает

Меньше. Он интринсиками инты забирает из памяти (если нэтив ордеринг влючен), тогда как обычный буфер вынужден по одному за раз таскать.

да тут чё рассуждать, на самом деле, заменой по сорцам allocate на allocateDirect и всё, другой способ пробовать ) главное бенчи нормальные на это дело

да нет там никакого оверхеда

запустите плиз бенчмарк на линуксе

все же дома сидят, какой линукс

@fomkin как вариант можно unsafe.get без проверок делать

@fomkin как вариант можно unsafe.get без проверок делать

Мне нужна функиональность ByteBuffer.

@fomkin запусти бенч на линуксе

сдается мне, эт маковская фишка

@fomkin как вариант можно unsafe.get без проверок делать

ну нахер этот ансейф, его уберут и че, как ОК сидеть и ныть на эту тему или ждать panama?

ну direct тож unsafe юзает)

ну direct тож unsafe юзает)

только директ останется и дальше в паблик апи

ну direct тож unsafe юзает)

Когда его уберут, он будет юзать что-нибудь другое. На то это приватное API. Его просто заменят на более приватное.

да никуда unsafe не денется

пока не парьтесь

честно честно?)

ERROR: S client not available

он же в 9 уже с ключом только

сдается мне, эт маковская фишка

Здается мне что это слишком простой бенчмарк.

@fomkin возможно

@fomkin а я все ще сомневаюсь, что ты правильно проблему идентифицировал. у тебя объекты маленькие и хранить их за пределами хипа тебе же накладнее будет.

Vadim дерево то не маленький обьект

Вот тут картина совершенно другаяю https://www.javacodegeeks.com/2013/08/which-memory-is-faster-heap-or-bytebuffer-or-direct.html

@fomkin там и год другой

"Java is becoming new C/C++ "

@fomkin а я все ще сомневаюсь, что ты правильно проблему идентифицировал. у тебя объекты маленькие и хранить их за пределами хипа тебе же накладнее будет.

Дерево вообще не маленькое. Тысячи объектов которые могут попасть в старое поколение и десятки тысяч объектов функцонального мусора.

Aleksey тем не менее у тебя будут убиваться ноды в дереве в оффхипе?

или ты их просто перезаписывать будешь?

Aleksey тем не менее у тебя будут убиваться ноды в дереве в оффхипе?

и вообще, че ты тут сидишь лясы точишь, иди SN пили, само не запилится )))

а еще момент интересен, а если дерево с другого треда решат посмотреть?

Aleksey тем не менее у тебя будут убиваться ноды в дереве в оффхипе?

Не будет дерева больше. Будет последовательность опкодов.

@fomkin я пока не понимаю, что ты сделать хочешь)

@fomkin я пока не понимаю, что ты сделать хочешь)

Есть RenderContext https://github.com/fomkin/levsha/blob/master/src/main/scala/levsha/TemplateContext.scala#L17. У него есть текстовая версия https://github.com/fomkin/levsha/blob/master/src/main/scala/levsha/TemplateContext.scala#L26 и будет версия которая пишет в буфер опкоды. Потом я в цикле по этим опкодам прохожусь и получаю ченьджсет.

хм

да, диф искать будет фаном)

да, диф искать будет фаном)

Какие сложности ты видишь?

я вижу сложность использования for

для большого дерева

хотя если есть offset то может быть норм

я вижу сложность использования for

Фор - дорого. Там лямбда и итератор. Будет вайл.

вот вам и ФП :)

Фор - дорого. Там лямбда и итератор. Будет вайл.

не принципиально, по гигабайтному дереву бегать стремно)

/stat@combot

combot.org/chat/-1001034178083

combot.org/chat/-1001034178083

вопрос, а какой клиент обычно юзают для работы с кафкой? Или все сами оборачивают java либу?

я что-то не могу догнать