А на счет 20К объектов в секунду - тоже такое себе...

мне надо возвращать ленту новостей юзерам - у каждого она своя, с БД вьігребается уже нужньіе обьектьі с нужной сортировкой, на стороне язьіка нужно только етот список конвертнуть в JSON и отправить юзеру, все

А точно не БД?

не понял вопроса :)

как бьі тьі сделал? :)

А на счет 20К объектов в секунду - тоже такое себе...

стандартньій подход же

стандартньій подход же

Ну не знаю

Для меня объект созданный из класса - это что-то такое, что точно будет жить дольше чем 0.001-1 сек...

в Java нет структур :)

Если нужно просто вычитать из БД и преобразовать полученный вариант в JSON - так это прям штамп сверху: Структура!

как бьі тьі сделал? :)

Структурой

ужс) я не о том тебе говорю

Хорошо

Давай тогда скажу, как бы я без структур делал

В таком случае, я бы сделал пул объектов

И использовал бы этот шаблон

И дал бы он просто колосальный выхлоп

В этом случае

Т.к. ты бы не удалял и не создавал объекты

А создал бы разово и держал бы их

Вот и все

СМ отдыхал бы и не вмешивался

Более того, для этого функционала его можно было бы даже отрубить!

Чтобы он даже не следил за этой памятью

Т.к. ты бы сам управлял этими объектами

Вот тебе и работа с объектами класса, и инкапсуляция, и твои любимые 20 объектов на каждый запрос

Так тебе сойдет?

И снова это нас подводит к тому, что не СМ плохой, а то, как пишет разработчик! Нужно заранее проектировать и понимать, что ты делаешь высоконагруженный проект

:) сойдет

А значит и подходы должны быть отличными от того, чтобы для каждого запроса создавать свои 20 объектов, чтобы перегнать их в JSON и заставлять СМ следить за ними и удалять сразу, как только тебе понадобился новый кусок памяти

И создал бы таймер, который запускался бы раз в 5-10 минут и удалял ОЧЕНЬ старые объекты

Сейчас нарвусь на то, что это костыль

Что это ручной СМ...

И всякое такое

@asan13 перечитай еще раз все :) где я писал о миллионе? есть 1000 паралельньіх запросов, где я ЗА ОДИН РАЗ КАЖДОМУ ПОЛЬЗОВАТЕЛЮ ОТПРАВЛЯЮ ТОЛЬКО 20 записей (пагинация, я писал), 1000 пользователей * 20 = 20к обьектов в секунду

я не про твой случай, выше увидел про миллион объектов из БД :) касательно 1000 клинтов по 20 записей - и что, реально GC ощутимо фризит, этло реальный сервис?

Но это HL, а значит подходы должны меняться! Влоть до того, чтобы работать без объектов

И снова это нас подводит к тому, что не СМ плохой, а то, как пишет разработчик! Нужно заранее проектировать и понимать, что ты делаешь высоконагруженный проект

да тут просто надо сравнить GC в D vs Go vs Java

Если он медленнее них, значит он плохой, без вариантов =)

Согласен, тогда он будет хуже

НО!

Если ты реально напишешь тест 1 в 1

Тогда поверю

А не так - Ну тут для GO подругому не сделаешь, так что я решил сделать так

1 в 1

Иначе тест не имеет смысла

Ну конечно реализации должны быть сопоставимы

Если сравнивать чисто GC, то результат довольно предсказуем (Дишный прососет). Ибо там сам подход разный: в языках с инкрементальными и generational GC пожертвовали скоростью основного кода, зато обеспечили короткие паузы на сборку мусора. В Ди наоборот - основной код работает быстро как в Си, без издержек на write barriers, но за это платят медленным GC. Поэтому нужно с умом подходить к тому, в каких задачах и как лучше применять Ди, и поэтому стоит сравнивать итоговую производительность идиоматичного кода, а не одинаковый код на разных языках. Что хорошо работает в Жяве плохо годится для Ди.

Наверно идеально было бы если бы можно было выбирать между разными имплементациями GC - либо он по чуть чуть подчищает, либо долго ждет и сразу помногу

Наверно идеально было бы если бы можно было выбирать между разными имплементациями GC - либо он по чуть чуть подчищает, либо долго ждет и сразу помногу

Зачем?

Под разные задачи - иногда важно подчищать по чуть чуть, а иногда надо отработать очень быстро и потом много почистить

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

А если просто почаще вызывать GC.collect() это будет не то же по эффективности?

Нет, он будет всю кучу обходить, вместо того чтобы один кусочек.

Весь цимес инкрементальной и generational сборки в том, что при очередном цикле сборки обходим лишь небольшой кусок кучи. Но для этого надо быть уверенным, что если основной код что-то поменяет в уже пройденном сборщиком куске, то сборщик об этом узнает.

А в go я так понимаю как раз инкрементальная сборка?

я у себя пробовал вызывать GC.collect() каждый кадр. Занимало по 5-7 мс

А в джаве какая?

В Go и Java инкрементальная и параллельная, да (в джаве еще выбор есть из нескольких алгоритмов).

а у нас не инкрементальная? о_О

Нет, полноценная

Last time I checked в D сборщик каждый раз все обходил. Потому и тормозит.

Блин, надо короче разобраться в DMD уже и контрибъютить(

Так сообщество не пойдет на внесение write barriers

Ибо сразу будет потеряно свойство "быстро как в Си"

Если честно то это и хорошо как по мне =) Не нужно всяких мусор в код вставлять

Тогда в случае невысоких нагрузок в D все хорошо, а в случае высоких распадаемся еще на два варианта - высокие пульсирующие, и высокие постоянные. В первом случае можно подчищать память в перерывах между нагрузкой, а во втором придется отказаться от встроенного GC или написать свой какой-то.

Тогда в случае невысоких нагрузок в D все хорошо, а в случае высоких распадаемся еще на два варианта - высокие пульсирующие, и высокие постоянные. В первом случае можно подчищать память в перерывах между нагрузкой, а во втором придется отказаться от встроенного GC или написать свой какой-то.

так а нельзя прибегнуть в умным указателями вместо GC?

ERROR: S client not available

во втором варианте?

Для веб-сервисов хорошо использовать allocator building blocks, так чтобы каждый обработчик запроса использовал свой кусочек памяти, который после завершения запроса моментально объявляется свободным. Так и аллокация дешевая, и расходы на сборку нулевые по сути. Технически с std.experimental.allocator это делается, но нужна дисциплина при написании кода.

Можно, но пользоваться фобосом тогда сложно, а он много где требуется.

GC - часть фобоса или компилятора?

формально - часть рантайма. Но компилятор опирается на его API

то есть чтоб встроить гипотетический GC надо форкнуть фобос?

Я так подозреваю что там все подряд придется форкнуть

там предусмотрена возможность включения своего GC, если он по API совместим. Даже ничего заменять и пересобирать не надо.

интересно

Но если хочется фич инкрементальности, то это надо весь компилятор форкать

По крайней мере раньше работала установка proxy: https://github.com/dlang/druntime/blob/master/src/gc/proxy.d Я так делал анализ статистики и замену дефолтного аллокатора на арену.

Теперь еще есть какой-то выбор варианта GC через конфиг, прямо в рантайме. https://github.com/dlang/druntime/blob/master/src/gc/config.d

string gc = "conservative"; // select gc implementation conservative|manual

Кто использует Вайб?

Если разобраться, что именно вы используете от фреймворка?

Это не тролинг

Интересно

В паре проектов - простой раутинг и отдача бинарных данных и простого html (без шаблонов diet). Еще в одном проекте использую WebSocket клиент из вайба внутри десктопного приложения. Для этого в отдельном потоке крутится эвентлуп вайба. Несколько лет назад еще делал простенький веб-проектик, там были diet шаблоны и авторизация.

Если разобраться, что именно вы используете от фреймворка?

vibe.data.json

vibe.data.json

и только из-за сериализации

Ясно

Базы данных его конекшен пул вроде еще умеют юзать

Вопрос. А кто что использует для создания схем миграций БД. Как я понимаю эта штука нужна чтобы неудачные изменения можно было откатить

схема миграции - нет такого понятия

Есть миграция, а есть схема БД

http://www.liquibase.org/

В крайнем случае есть миграция схемы

Вопрос. А кто что использует для создания схем миграций БД. Как я понимаю эта штука нужна чтобы неудачные изменения можно было откатить

Не только для того, чтобы откатить

Чтобы можно было запустить и с 0 развернуть работающую БД

Очень полезная штука

А их руками пишут и через орм? Я правильно понимаю они нужны чтобы изменения откатывать/применять

Да