LINUX.ORG.RU

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

Исправление aist1, (текущая версия) :

То, что у меня там unordered_map, не должно сбивать с толку. Что было под рукой, то и влепил, зная, что потом легко могу заменить на более производительный контейнер. Просто эти «более производительные» могут вести себя «странно», что может добавить проблем при отладке. И всякие такие оптимизации имеет смысл делать тогда, когда подсистема уже устоялась (т.е. после make it correct).

Я когда Меморию только начинал, я по производительности упарывался. И сразу писал «самый быстрый код» и «самую высокопроизводительную архитектуру». Потом я задолбался это всё вместе отлаживать и переписывать, и полюбил простой, понятный, предсказуемый, стабильный и медленный код (который, тем не менее, всё равно будет быстрее той же Java). Кто-то всю жизнь пишет один этот несчастный (или счастливый) кэш, вылизывая его до умопомрачения. А у меня, условно, 1000 таких «кэшей» в архитектуре, причем самописных. И если что-то останется медленным, то, «не судьба». Я фокусируюсь на «make it correct». Ты не доверишь свои данные БД, которая их теряет. Какая бы быстрая она не была. Понимаешь?

Исходная версия aist1, :

То, что у меня там unordered_map, не должно сбивать с толку. Что было под рукой, то и влепил, зная, что потом легко могу заменить на более производительный контейнер. Просто эти «более производительные» могут вести себя «странно», что может добавить проблем при отладке. И всякие такие оптимизации имеет смысл делать тогда, когда подсистема уже устоялась (т.е. после make it correct).

Я когда Меморию только начинал, я по производительности упарывался. И сразу писал «самый быстрый код» и «самую высокопроизводительную архитектуру». Потом я задолбался это всё вместе отлаживать и переписывать, и полюбил простой, понятный, предсказуемый, стабильный и медленный код (который, тем не менее, всё равно будет быстрее той же Java). Кто-то всю жизнь пишет один этот несчастный (или счастливый) кэш. А у меня, условно, 1000 таких «кэшей» в архитектуре, причем самописных. И если что-то останется медленным, то, «не судьба». Я фокусируюсь на «maker it correct». Ты не доверишь свои данные БД, которая их теряет. Какая бы быстрая она не была. Понимаешь?