ДК
Ну вот у меня тоже была гипотеза, что под капотом он всё-равно хеш-таблицу и там и там использует. Но думаю тут дело именно в том, что набор полей постоянно меняется.
Size: a a a
2021 November 29
ДК
Поэтому эффективней как раньше - иметь ограниченный набор полей (не более числа декорированных методов), а неограниченные лучше выносить в отдельный объект. Тогда первый может быть оптимизирован скрытым классом, а второй даже не будет пытаться.
ДК
Можно, кстати, попробовать не для каждого реестра заводить по мапке, а иметь одну мапку для всех свойств с ключами.
SY
тогда имя метода должно быть в ключе
SY
или ты про то, что в объект же ты пишешь только для отладки, и можно вообще только ссылку на реестр всех mem-свойств
ДК
Агась, типа такого.
ДК
Не, в объект я пишу, чтобы при повторном обращении к свойству - брать существующий атом, а не создавать каждый раз новый.
SY
this.__atoms = new Map<PropertyName + Key, $mol_atom>()
SY
я про то, что вообще можно только одно свойтсво для отладки писать в хост
SY
а все остальное в мапе
SY
бенчи на мапы не делал, что лучше много мелких мап или одна большая?
ДК
Ну вот сейчас погонял, разницу не заметил.
SY
только ключи надо отделять символом каким-нить, т.к. конфликты могут быть: propA+key может быть = propB+key и перезатрет его
ДК
Разумеется, ключи тут окружены скобочками.
SY
значение ключа тоже может скобочки содержать
ДК
А значение свйства - нет, так что не важно, что там в ключе.
ДК
Но я лучше оставлю как тут. Производительность та же, а отлаживать всё же проще.
2021 November 30
O
Что-то очень интересное обсуждали выше, жаль не понял :(
ПЗ
фейки (