увы, нашему брату ничего не заходит. даём инфу про крутые решения - "голимая реклама", проводим технические вебинары - смотрят единицы. в этой связи накатал тут в телеге. сюда решил репостнуть
внимание вопрос: через одну минуту ответьте, пожалуйста, Ивану, почему данное видео с разбором наиболее частых ошибок в проектировании приложений с реальными примерами за 8 месяцев набрало всего 26 просмотров? неужели тема ускорения приложений ни для кого не актуальна? или кому актуальна и руки из плеч, уже это знают, а кто в 21м году так и не озаботился ускорением своих БД Domino, никакие видео не помогут?
Потому что на одну половину весь доклад состоит из общеизвестных клише, а на вторую создаётся впечатление, что человек говорит о том, чего он лично не пробовал.
Вот для примера - говорит, что какой-то "один клиент в Финляндии нашёл...", что проверка строк на длину в разы быстрее, чем на пустоту строки. В отличие от оратора меня этот вопрос заинтересовал лет 15 назад как, я тогда же провёл эти тесты (правда на 6.5.1), которые выложил на сайте нотес.нет. Результат таков - никакого существенного прироста проверка Len не даёт, - выигрыш менее 1%.
Я сам, естественно, всегда использую Len, потому что перфекционист, но я не буду никому рассказывать о каких-то там приростах, потому что пробовал эти устрицы. Если же в более поздних версиях что-то поменялось в лучшую сторону, то я уже точно ничего от этого не выиграю, т.к. весь код у меня и так на Len-проверках.
Или про цикл, что For быстрее.
Для случаев частого изменения данных в ходе работы с циклом документ может "исчезнуть" с разной "степенью тяжести" - от того, что может быть просто удалён (будет Nothing) либо пользователь резко может потерять к нему доступ (в случае выполнения кода на клиенте и наличии некоторых процессов, предполагающих это). К примеру, у нас такие случаи бывают нередко.
Хорошо, делаем код на For, но документ-то, учитывая вышеизложенное, всё равно нужно проверить как минимум на Nothing, и если мы это делаем, то потерялось всё преимущество от For, наоборот - мы выделили дополнительную память на переменную-счётчик. А ещё нужно проверить док, полученный из коллекции на IsValid и IsDeleted, для которых предварительная проверка на Nothing просто обязательна...
Ну и так далее, - можно комментировать по каждому пункту.
Мне это чем-то напомнило тесты для разработчиков Lotus от IBM, которые я ни разу так и не смог пройти, т.к. большая часть вопросов предполагала массу уточнений (на какой среде выполняется код, какие при этом были настройки клиента/сервера, и т.д.), которых в вопросах не было, потому ответить было невозможно.
И вот на таких выводах (что где-то что-то услышали) они сделали утилиту, которая оценивает код...
Ну даже если и покажет, что формулы в колонках видов неоптимальны, мы это и так знаем, но не будем переделывать, т.к. в среде, состоящей из более чем 50 баз, и сотни форм/подформ это очень трудоёмко и грозит большими неприятностями, если вдруг что-то такое затронешь. В итоге чем может нам помочь эта утилита? Ничем, т.к. ничего нового мы не узнаем, но нужно будет заплатить денег ребятам за труды.
Возвращаясь к производительности. Рассказанное и так понятно и немеряно раз пережёвано.
Скажу больше, - если нет явных таких косяков, на производительность больше влияет правильное проектирование системы.
Пример-1: Если создать вместо одного поля с доступами в документах, к примеру четыре - 'AcsAUsers', 'AcsAServers', 'AcsAGroups', 'AcsARoles', то ненужно будет перебирать огромный массив данных, для начала пытаясь понять, что это, пользователь, группа, сервер или роль, а соответственно можно взять чисто группы и применить разворачивание чисто к ним. Либо взять сервера и сделать какую-либо операцию для них.
Пример-2: На этапе проектирования заложиться на то, что в группах АК сервера не делать смешанного содержимого (пользователи+группы), а только что-то одно - либо то, либо другое.
Естественно такой подход очень сильно сэкономит ресурсы и увеличит скорость исполнения кода.
Вот это реально полезные вещи, которые приходят, когда ты построил одну СЭД, переписал её раз, два, три. А потом ещё на основе полученного опыта написал вообще новую, с полной параметризацией, начиная от вычисляемых имён видов, форм, полей, агентов и т.д.. А не то, что перечислять азы довольно-таки низкого качества с сильно однобокой подачей. Поэтому лично мне такой материал малоинтересен, по моему он непригоден для разработчиков. Ну, разве что, для админов, чтобы дополнительно было пару вопросов из перечисленных пообщаться на курилке))
Прошу прощения, но Вы хотели отзыв. Это максимально честно.
