Лично я вижу "ты не тянешь программистом/тестером - иди в манагеры, там зряплата больше"
Что в итоге? На еженедельном митинге сидят 3 программиста и 7 манагеров
Теперь уже два - я ушел на свободу - свое ИП - договора - и все такое. Дальше без меня
Забавно что 7 манагеров загружены по уши - настолько все забюрокрачено. Отчеты планы графики ХЗ что еще
Вот
Корень проблемы как мне кажется в том что манагеры вообще говоря не всегда нужны. Должна быть необходимость в манагере. Например реально огромный проект и надо координировать разные его компоненты. Или много студентов джунов которым надо рассказывать и объяснять что делать. Но если проект нормального размера (узко специализирован и не надо его раздувать!), три-пять хай-левел программистов - ну зачем здесь манагер? только мешать нам будет. :)
Если необходим конкурентный доступ к объекту в памяти многих читателей и нескольких писателей в идеале одного + объект крупный и-или сложный + читателей нежелательно задерживать + размер памяти позволяет держать одновременно два объекта старый и новый = данный алгоритм подходит.
У нас объекты это десятки или сотни мегабайт данных (правила межсетевого экрана) а читатели это обработчики сетевых пакетов.
В случае именно сборки мусора то есть автоматического распределения памяти в общем случае выбор такого алгоритма как мне кажется это перебор. Для небольших объектов с коротким временем жизни без необходимости конкурентного доступа - зачем? А ведь таких большинство. Как опция - возможно
привет Макс!
Лично я вижу "ты не тянешь программистом/тестером - иди в манагеры, там зряплата больше"
Что в итоге? На еженедельном митинге сидят 3 программиста и 7 манагеров
Теперь уже два - я ушел на свободу - свое ИП - договора - и все такое. Дальше без меня
Забавно что 7 манагеров загружены по уши - настолько все забюрокрачено. Отчеты планы графики ХЗ что еще
Вот
Корень проблемы как мне кажется в том что манагеры вообще говоря не всегда нужны. Должна быть необходимость в манагере. Например реально огромный проект и надо координировать разные его компоненты. Или много студентов джунов которым надо рассказывать и объяснять что делать. Но если проект нормального размера (узко специализирован и не надо его раздувать!), три-пять хай-левел программистов - ну зачем здесь манагер? только мешать нам будет. :)
Мы используем подобный алгоритм в продуктах
Если необходим конкурентный доступ к объекту в памяти многих читателей и нескольких писателей в идеале одного + объект крупный и-или сложный + читателей нежелательно задерживать + размер памяти позволяет держать одновременно два объекта старый и новый = данный алгоритм подходит.
У нас объекты это десятки или сотни мегабайт данных (правила межсетевого экрана) а читатели это обработчики сетевых пакетов.
В случае именно сборки мусора то есть автоматического распределения памяти в общем случае выбор такого алгоритма как мне кажется это перебор. Для небольших объектов с коротким временем жизни без необходимости конкурентного доступа - зачем? А ведь таких большинство. Как опция - возможно
кстати екзешник там странный 212480 байтов
многовато
я перекомпилил сорцы получил 8704 :)