История изменений

Второй движок не просто так появился. Монадическое связывание на Scott encoded Free монады имеет квадратичную сложность, поэтому я заменил ее на Church encoded Free монаду. Производительность сразу же подскочила в 10 раз. Потом еще избавился от глупого GUID в пользу целочисленного. Производительность снова подскочила в 10 раз. А до этого, еще когда готовил версию 0.4, исправил конкурентный баг, который приводил к излишним перезапускам транзакций (но все же не портил верные результаты).

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

Собственно, в этом-то и риск: если вы сами не используете свою разработку в реальных задачах, то кто знает, что там еще может боком вылезти. А когда вылезет, то насколько вы готовы будете с этим разбираться.

Я понимаю

Не думаю, что вы понимаете о чем я вас спрашиваю. Раз уж упомянули наш проект, то из опыта его эксплуатации. Один из моментов, который практически сразу же всплывает: «А как посмотреть, что у вас происходит внутри?» Т.е. когда ты вроде делаешь все по документации, а оно почему-то не работает, то как узнать, что и где прервалось.

Второй момент — отмена таймеров. Таймер можно отменить, но если это примерно совпадает со временем срабатывания таймера, то таймерное событие до вас все-таки может дойти. Это не очевидно для пользователей, но этому есть объяснение.

И мы объясняем пользователям вещи, с которыми при эксплуатации кто-то да сталкивается.

Собственно, если вы позиционируете cpp_stm_free как практичный инструмент, то можете ли вы рассказать о том, на что нужно обращать внимание при его использовании? Скажем, вы говорите «Сейчас известно, что STM порождает большой memory-трафик, и происходят множественные копирования данных, которые вы помещаете в TVar», а мониторить это как-то можно? Статистику какую-то снимать в каком-то виде?

Второй движок не просто так появился. Монадическое связывание на Scott encoded Free монады имеет квадратичную сложность, поэтому я заменил ее на Church encoded Free монаду. Производительность сразу же подскочила в 10 раз. Потом еще избавился от глупого GUID в пользу целочисленного. Производительность снова подскочила в 10 раз. А до этого, еще когда готовил версию 0.4, исправил конкурентный баг, который приводил к излишним перезапускам транзакций (но все же не портил верные результаты).

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

Собственно, в этом-то и риск: если вы сами не используете свою разработку в реальных задачах, то кто знает, что там еще может боком вылезти. А когда вылезет, то насколько вы готовы будете с этим разбираться.

Я понимаю

Не думаю, что вы понимаете о чем я вас спрашиваю. Раз уж упомянули наш проект, то из опыта его эксплуатации. Один из моментов, который практически сразу же всплывает: «А как посмотреть, что у вас происходит внутри?» Т.е. когда ты вроде делаешь все по документации, а оно почему-то не работает, то как узнать, что и где прервалось.

Второй момент — отмена таймеров. Таймер можно отменить, но если это примерно совпадает со временем срабатывания таймера, то таймерное событие до вас все-таки может дойти. Это не очевидно для пользователей, но этому есть объяснение.

И мы объясняем пользователям вещи, с которыми при эксплуатации кто-то да сталкивается.

Собственно, если вы позиционируете cpp_stm_free, то можете ли вы рассказать о том, на что нужно обращать внимание при его использовании? Скажем, вы говорите «Сейчас известно, что STM порождает большой memory-трафик, и происходят множественные копирования данных, которые вы помещаете в TVar», а мониторить это как-то можно? Статистику какую-то снимать в каком-то виде?