Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Даже если бы так было, ты бы вряд ли заметил замедлениеFlasher писал(а):При каждом вызове любого окна считываются все хэши на предмет класса и разрешения?
Разумеется, сделано не так. Хэши "независимые" считаются один раз для всех диалогов при запуске (как хорошо и эффективно было в первом варианте...). "Зависимые" - один раз для одного диалога при каждом открытии диалога (можно, конечно, и здесь чуть оптимизировать, но лень). Далее секции читаются и пишутся напрямую.А как ты отличаешь зависимые от независимых без перечёта всех хэшей?Loopback писал(а):"Зависимые" - один раз для одного диалога при каждом открытии диалога
И всё равно непонятно, зачем писать разрешение в хэш, если можно вдвое сэкономить на секциях? Или хэш меняется при смене разрешения независимо от склейки?Loopback писал(а):При изменении разрешения строка разрешения поменяется, опять будет другой хэш.
Насчёт "вдвое" я, конечно, слукавил:Loopback писал(а):По "экономии" секций даже говорить не о чем, нет никакой принципиальной экономии, условно говоря, какая разница, 100 значений по 50 в 2 секции или по 4 в 25.
В рамках запуска одного окна не кучу, а всего 4. И тебе, если я правильно понял, не придётся по новой считать хэши:Loopback писал(а):зато не надо делать кучу конкатенаций для чтения каждого значения в виде хэш_Left и т.д.
Уж явно 4 конкатенации по скорости значительно быстрее вычисления хэша.Loopback писал(а):Хэши "независимые" считаются один раз для всех диалогов при запуске
Я сейчас больше интересуюсь не в целях перекомпиляции, а скорее в образовательных.Loopback писал(а):плюс реализация уже была сделана, удобная и быстрая, зачем изобретать велосипед?
Замерять не буду, но не факт, хэш простейший, криптостойкость же ему не нужна. Плюс есть как минимум два пути оптимизации, может даже и сделаю один (расчет зависимого на основе независимого), тогда будет точно быстрее. Но на самом деле реально не вижу необходимости, на строках в пару десятков символов это микросекунды, а у нас не какие-нибудь нагруженные базы данных, где это будет хоть как-то заметно.Уж явно 4 конкатенации по скорости значительно быстрее вычисления хэша.
Это понятно, про переделывать я и слушать не стануинтересуюсь не в целях перекомпиляции
Посему предлагаю заканчивать, раз все равно ничего меняться не будет.Было бы понятно, не спросил бы про велосипед.Loopback писал(а):Это понятно
Про переименование уже думал, как минимум хорошо бы главную функцию переименовать (для совместимости можно псевдоним добавить). Если переименовать сам плагин, его старая версия останется лежать мусором, к сожалению, тоталовский инсталлятор плагинов не умеет удалять файлы.Flasher писал(а):. Я бы ещё переименовал плагин под новые реалии.
