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

Ну то есть факт возможности фризов ты признаешь? =)

я и не отрицал, что в D GC так себе)

я говорю, что в подавляющем большинстве случаев в приложениях с нормальной архитектурой это не самое узкое место)

а когда оно становится узким, можно включать C-style)

То есть по сути ты предлагаешь отказаться от GC и делать без него.

Потому что никак по другому ты это узкое место не оптимизируешь.

собственно, стандартная библиотека постепенно к этому идет)

vibed сейчас вот частями переписывают, попутно уменьшая зависимость от GC

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

Да не очень то имхо, ну там может несколько десятков МБ освобождалось, как-то так.

в go задержки gc не бульше 10 мс :)

в go задержки gc не бульше 10 мс :)

после 3х секунд это грандиозный прогресс

Да они его на протяжении всего времени вылизывают как могут

Очень много сил на него тратят

ну так круто) я не хочу заморачиваться nogc и тд, я хочу чтоб автомато gc все решал хорошо

вон в java проблем с етим не бьіло еще

кстати, как отстраненный пользователь Eclipse, никогда толком не использовавший в работе java, могу сказать, что в ней проблемы с памятью и фризами в принципе перманентны)

уж не знаю, связано ли это с криворукостью разработчиков или с кривостью виртуальной машины)

Ну память она жрет хорошо, про фризы вроде не слышал проблем

Ну такое

Если писать не разбрасываясь объектами на лево и на права, то в СМ проблем не будет

Имхо

в go задержки gc не бульше 10 мс :)

Это маркетинг булшит. Т.е. в идеальном случае, когда аллокаций немного и фоновый поток с ГЦ успевает все подчищать, тогда они стараются в эти 10 мс уложить остановки мира (но не забываем, что считай целое ядро постоянно трудится над сборкой в параллель основной программе). И надо понимать, что эти 10 мс могут быть каждые 10-15 мс, т.е. занимать до 90% всего времени. :) А если аллокаций становится больше, то чудес не бывает, сколько потребуется ГЦ на сборку, столько и займет. Невозможно гарантированно собрать кучу любого размера за 10 мс.

кстати, как отстраненный пользователь Eclipse, никогда толком не использовавший в работе java, могу сказать, что в ней проблемы с памятью и фризами в принципе перманентны)

еклипс криворукие писали, попробуй IDEA, та єе джава - все ок

тот же spring может под нагрузками месяцами работать... vibe.d так умеет?

Не уверен

Ну впринципе если ожидать что некоторые запросы будут отрабатывать за полсекунды (что не так уж плохо для web). то он будет работать.

я о том что если простом разработчику нужно думать в D о GC, оптимизировать там что-то, то D тогда плохой язьік

ну в плане тогда он не лучше Java, и смьісл его использовать нет

Ну простой разработчик HL проект и не пишет)

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

А если он слепо создает массу объектов там, где можно обойтись несколькими - то тут не в языке дело! И не в СМ...

И язык не должен ограничивать от такого

Иначе он будет сильно "узок"

имхо

почему я не могу создавать масу обьектов? :)

в джаве создаю - все ок

вот пример, есть загрузка в 1000 запросов в секунду, где надо вернуть массив по 20 обьектов (пагинация все дела), как тут не создавать кучу обьектов?

короче, предлагаю проект выходного дня: делаем хотя бы приблизительно похожие мини-проекты на java и D (vibe) и тестим их под нагрузкой)

смотрим результаты

вот пример, есть загрузка в 1000 запросов в секунду, где надо вернуть массив по 20 обьектов (пагинация все дела), как тут не создавать кучу обьектов?

Думать если и придется, то сильно меньше чем в php/python для этого. Там придется вообще изначально масштабироваться и оптимизировать архитектуру.

А в D, ну возьмешь какой-нибудь готовый Object Pool, и на этом вся работа =)

по итогам проекта можно выносить вердикт и составлять план будущих работ)

:) ну я за, rest клиент, которьій возвращает массив с 20 обьектов как жсон, в обьекте 15-20 полей (Data, string, int...)

обьектьі при кажном запросе создаются новьіе и набиваются какойто статикой

ну тут сразу появляется вопрос: а зачем объекты?)

в джава другого нет) можешь структурьі использовать, но тогда как тьі gc потестируешь?

вот пример, есть загрузка в 1000 запросов в секунду, где надо вернуть массив по 20 обьектов (пагинация все дела), как тут не создавать кучу обьектов?

Я сказал там, где можно обойтись без них

Если так хочешь делать - ради Бога

Но ты должен понимать, что СМ прийдется их удалять

что такое CM?

И создать объект только для того, чтобы его создать (скопировать или еще что-то) - это не верно

Сборщик Мусора

Я не против объектов

Я против их использования там, где они не нужны

Используй структуры

Это быстрее и практичней

а как не создавая? представь что каждьій запрос просит разньіе данньіе с БД, которьіх там сотни тьісяч

Структуру юзай

нашей целью должна быть не проверка сборщика мусора, а проверка пригодности D с его специфическими подходами для использования в продакшене)

структурьі надо ручками удалять?

Тоже объект, но с слабой инкапсуляцией

структурьі надо ручками удалять?

Нет

структуры удаляются вместе со всем стеком, ибо они на стеке)

структуры удаляются вместе со всем стеком, ибо они на стеке)

Так вот тебе и плюс

а когда стек удаляется?

А нужна долгая работа с ним - фигаш его дальше по ссылке

и в D там, где не нужно наследование, лучше использовать именно их)

ERROR: S client not available

и в D там, где не нужно наследование, лучше использовать именно их)

Не только в Ди. В С++ тоже

а когда стек удаляется?

когда происходит возврат из функции

Объект, который описывает запись в БД, имхо, лучше представлять ввиде структуры

А вот обработку этих данных можно инкапсулировать и в каком-то классе

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

кстати, тут кто-то хотел fastcgi писать с использованием vibe-core, далеко ли дело продвинулось?)

Делай структуру. Создавай Класс работы с этой структурой

Ты же изначально целишься на высокие нагрузки

ну иак я не против) структурьі так структурьі

Смотри ситуацию:

В БД у тебя 1М записей

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

Создавать 1М объектов из классов, чтобы сделать такие операции - ну крайняя расточительность

А вот структуры еще куда не шло...

Да и то, лучше это выруливать SQL запросами и выборкой только нужных записей

Да, чуть усложняется сама задача в плане - а зачем так???

Но это правильно!

А вот многие программисты так не делают, бо так нужно SQL group by писать...

Документацию читать

Получать низкий уровень работы с БД, а не простым db.findAll()

Вот, что я имел ввиду, когда говорил не создавать просто так много объектов

Ну а если тебе реально нужно их создавать, то тут без вариантов!

И тот же GO тоже будет существенно подвисать, если ты создаш 1М объектов и потом заставишь очищать эту память

Потому, что новому запросу вот УЖЕ нужна эта память, а не когда-то там в будущем

Опять таки все уперается в разработчика

И его лень

при чем тут вьігребать все обьектьі с БД)) ясно что упадет нафиг при таком роскладе

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

миллион записей тащить на клиент странный кейз

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

но обьектьі каждьій раз разньіе, их кешировать/переиспользовать не получится

Я привел пример.