| повторяю прописные истины |
[Nov. 28th, 2013|11:49 am] |
не надо, совсем почти никогда не надо пытаться сразу написать более-менее оптимальный код. продумывать архитектуру и API, чтобы можно было написать такой код — надо. а вот писать такой код в самой первой реализации не надо.
это я к чему? к тому, что etx engine кэширует информацию о строках — позицию, размер, высоту, ширину… это всё периодически надо знать, и каждый раз считать будет долго.
натурально, кода информация нужна, сначала пинается внутренняя функция «обеспечь мне валидный кэш до вот этой точки».
натурально, при изменении текста функции-мутаторы (ну нравится мне это слово) могут бережно обновлять кэшированое значение для строки, котрую меняют, прямо на месте. и это во многих случаях будет быстрее, чем считать всё даже для одной строки заново. и функции перемещения по тексту могут держать номер строки и так далее в синке. но.
но. если я буду это писать сразу, то придётся и больше кода ебошить, и оттестировать будет сложнее. поэтому пишу тупо, борясь с желанием немедленно всё оптимизировать: при любом изменении/движении просто сбрасываю нахуй кэши. да, это тормозит. зато можно намного быстрее собрать рабочий прототип и убедиться, что он работает именно так, как надо.
а когда прототип заработает, каждую из функций можно нежно оптимизировать, проверяя по пути, не сломалось ли что-нибудь: пользователям движка это будет уже совершенно похуй. и при возникновении бага я буду знать, где я его сделал и где его следует искать.
понятно, что вышенаписаное — вещь совершенно очевидная. но тем не менее лично я каждый раз ловлю себя на том, что для написания «дубового» кода мне надо прикладывать больше усилий, чем для написания «оптимизированного». потому что при виде «дуба» мне хочется немедленно всё переписать, ибо «ну, очевидная же оптимизация, я должен её сделать!» приходится каждый раз тормозить себя усилием воли.
но в конце концов это окупается, потому что написаный сразу «оптимальный» код нещадно глючит, а отладить его сильно сложнее, чем «дубовый»: хуй же знает, где там именно ошибка, слишком дохуя всякого написано.
а ещё у «дубового» кода есть и такое преимущество: можно релизнуть библиотеку прямо с ним. и тогда или кто-нибудь оптимизирует за тебя, или сделать самому и через некоторое время релизнуть новую версию, с крутой строкой в анонсе: «базовые операции ускорены на 100500%, вау!»
тут главное — не наткнуться на какого-нибудь умника, который решит вместо присылания патчей или ожидания новой версии написать у себя в бложеге про то, какой же ты мудак и какой говнокод ты засунул в релиз. с примерами. попробуйте защитить себя от такого при помощи жалобных комментариев по всем исходникам: «да, я знаю, что это говнокод и ни разу не оптимально. но я хотел релизнуться как можно раньше, а эти куски я уже переписываю, честно-честно! не сплю ночами, и в следующем релизе всё-всё перепишу как надо!»
в принципе, такие комментарии позволяют не трогать говнокод вообще, достаточно в release notes где-нибудь очень в конце дописать: «увы, я не успел сделать все планируемые оптимизации к этому релизу». обычно умники не проверяют код больше пары раз, а пару раз их можно ткнуть в release notes и рассказать, как ты старался дать им библиотеку, ночами не спал, а они срут тебе прямо в душу. |
|
|
![[info]](http://lj.rossia.org/img/userinfo.gif){kind=small}
