Алексей Уколов: Видимо речь про имутабельность общего стора, когда нужно хранить все срезы.
Идея интересная - экономия памяти и не нужно клонировать стор. Наверное дело в том, что никому не надо хранить историю/срезы.
Ещё иерархия в 1000 этажей может быть медленнее, хотя не критично, хотя можно периодический сбрасывать.
1) Замените al-app на al-app="app" (это вызовет глобальную ф-ию)
2) Добавьте глобальную функцию app из этого примера (функция содержит метод show)
3) Добавьте :hidden="!show('pediatric', 'new-york')" на элемент который должен исчезать, - будет вызываться метод show и скрывать элемент в зависимости от результата
js (v8) гораздо быстрей чем PHP, на некоторых алгоритмах догоняет С++ (на оптимизацию вбухано очень много денег).
Но голый js нет смысла использовать, т.к. он ничего не умеет, если его использовать как расширение или в nodejs, то скорость и ценность сильно падает.
Можно сделать фильтр который и будет вытаскивать инфо, например {{product.acc_id | get: 'account'}}
У меня в проектах с Angular Light, где-то есть такое: {{#get product.acc_id -> account.company_id -> company.name}} - асинхронно тянет с сервера всю цепочку (если она не закеширована)
wpbloger: > А как насчет не долгих блокировок, чтение/запись в бд в основном происходят за 50-100 мл секунд, но даже вроде в этом случае это должно дать положительный эффект нет?
В общем случае нет:
1) если смотреть на конкретный запрос, то оба и синхронный и асинхронный вариант завершаться за одинаковое время (50-100 мс), т.е. зависит от БД.
2) Если смотреть под нагрузкой, много параллельных запросов, то асинхронный код будет проигрывать, если кол-во поток достаточно в много-поточной версии.
Например если рассмотреть конкретный запрос в БД на 50мс, если БД сможет потянуть в 10 потоков этот запрос, то она выдаст 200 rps и съест весь проц. в итоге на остатки ресурсов процессора веб сервер выдаст результат, итого будет не более 200 rps.
Если это не БД, а легкий запрос, или БД находится не на текущем хосте, тогда можно прикинуть так:
нужно выжать 5к rps, задержка 50мс, значит один поток 1000/50 = 20 rps, для 5k нужно 250 потоков.
Итого при 250 потоках, многопоточное приложение выиграет у асинхронного, т.к. асинхронному нужно тратить часть ресурсов на обслуживание самой асинхронщины и переключение задач, когда в многопоточном это делает ОС и проц максимально быстро.
Кстати (в питоне) 250 потоков могут съесть всего 7-20Мб памяти (зависит от приложения).
Идея интересная - экономия памяти и не нужно клонировать стор. Наверное дело в том, что никому не надо хранить историю/срезы.
Ещё иерархия в 1000 этажей может быть медленнее, хотя не критично, хотя можно периодический сбрасывать.