maytondbpatchпри этом отдельный ржач - в продакшине есть даже методика, когда выключают принудительно очистку old-generation, дескать дешевле просто на выходных приложение рестартовать и заново загрузить кеши из базы данных. вполне себе подход, чо
Вы наверное не в курсе. Вы просто не разрабатывали подобные приложения. Например
ПО обработки equities, options имеет ярко выраженный сутошный лайф-цикл. Биржа
открывается в определённое время суток. А потом закрывается. На момент закрытия
приложение никому не нужно. И его можно ребутнуть. Какую из этого можно получить
пользу? Я думаю - очевидно.

тебе-то из подвала оно конечно виднее. из суточных лайф циклов - про good till cancel/day ты тоже уже в курсе?

maytonПо поводу QNX. Иван решил отмолчаться. Ну ОК.

Из топиков по сабж я могу вспомнить только мой спор
с неким Petrav на тему ПО и самолетов. А также
с Базистом по поводу создания СУБД с нулевым
откликом.

Вообще у меня сложилось стойкое впечатление что
в форуме мало людей которые по существу могут пояснить,
а зачем им собственно вообще нужен реал-тайм. Обычно в 99%
бизнес задач такой вопрос вообще не стоит. Этот аспект
может быть описан так называемых NFR (Non functional
requirements) где-то одим из подпунктов. Там может
быть что flow, заявки на покупку или продажу акций
должен быть отработан не более чем за 300 мс. Но
это будет требование только для нашей системы. Не
для внешних микросервисов. Они могут лагать как им удобно.
Жесткий риалтайм в большинстве случаев это действительно не обязательное требование даже если его явно выдвигают.
Тут больше из отряда обеспечения запаса прочности.

Я в бытность потратил месяца два, чтоб обеспечить гарантированные 30к записей в секунду в default СУБД в продакшине.
Заказчик так захотел.
А на реальных продакшинах у него практически никогда не было больше 2к. В среднем.

А вот в пике - доходило до 20к.

А подобное разгильдяйское отношение к времени отклика оно куммулятивное - тут ты не обеспечил, там не обеспечил, а в результате
хрясь, в определенной ситуации у тебя и до time-out дошло, клиент потерял деньги, и тому подобное.

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

maytonПо поводу UI для систем с MM (managed memory).

Для UI приложений написанных на Java, есть коробочная
рекомендация - включать +UseConcMarkSweepGC.
Навскиду не помню но кажется эта опция включена
во все дефолтные конфигурации пусковых скриптиков
bash для продуктов комании Jetbrains. Этого достаточно
чтобы комфортно работать и не видеть т.н. stop-the-world
о которых так много говорят в топике.

P.S. Я прошу прощения что пишу только по Java. C .Net я давно
не работал и не в курсе как там и чего. Если кто в теме - то
дополните.
Да, продукты Jetbrains выглядят "повеселее" в плане отзывчивости и незалипаемости.
Хотя у них проблемы спонтанных тормозов все равно остаются, хотя как говорят наши джависты - это уже проблема
не самой JVM, а уже непосредственно кода IDE.

Тем не менее, сравнение с Visual Studio или Delphi IDE они до сих пор не выдерживают. Но, как говорят джависты - привыкнуть можно. Угум.

Anatoly MoskovskyИзопропилно эта "локальная" переменная - уже не может жить на стеке.
Физически она находится в замыкании. А само замыкание может храниться в локальной переменной, т.е. на стеке

хранение объектов на стеке - это "фича" C++, мало кто еще так делает. обычно на стеке хранятся лишь ordinals - int, pointer.
в этом ключе реализация замыкания довольно проста - ordinals просто копируются по значению,
а объекты - т.к. все равно в куче, мы копируем лишь указатель-ссылку на них

тут другое интереснее - переменные могут и на стеке не храниться, а прямо в регистрах исполняться, в т.ч. параметры функций.

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

впрочем, какая разница откуда копировать...

Модератор: Тема перенесена из форума "C++".