> забывал делать отмену watch и bind событий при уничтожении директив
Это хороший тон удалять "подписки", но в реальности оно зачастую не влияет, т.к. если директива удаляется то это значит что идет процесс разрушения scope, а при разрушении scope и DOM все подписки удаляются "автоматический".
UnoMomento: например этот https://www.yourserver.se/ обещают настоящий безлимит по объему (но лимит на ширину канала, что естественно, вроде было 100Мбит/сек для 4евро тарифа)
Это не замена, а добавка (оптимизация) к dirtychecking. Не думаю что её будут активно применять, просто "шумят", т.к. этому подходу "сто лет в обед" и кому надо уже давно используют.
Yaroslav Lyzlov: Отвечу про Ember за себя, в кратце:
1) тормозной
2) классы на классах классы погоняют
3) set/get - неудобно, прошлый век.
Сергей Протько: Я не смотрел, но думаю под капотом у в Angular 2 тот же "scope" или аналог, т.к. там dirtychecking, дак вот дочерние scope создаются так же с прототипом или там какие-то изменения?
Просто я нашел способ как можно не плодить scope на каждый чих (ngIf, ngInclude...) и при этом прототип не особо и нужен, в итоге данные в корне работают норм (сейчас нужно "точку в имя" что-б дочерние scope юзали), т.е. [[ {{v}} ]] будет работать нормально и быстрее т.к. нет трех-этажных прототипов.
Андрей Апанасик: ошибки есть, но дайте тесты где их нет.
Новая монга 3.2 тоже ускорилась и улучилась. Вообщем я пока не вижу преимуществ у RethinkDB, если смотреть снаружи то монга вроде как полностью перекрывает ресинк.
Если опустить тесты, что ресинк может предложить?
Я увидел что там есть "потоковое" получение данных, но нужно ещё проверить насколько оно "честное", хотя для этих целей лучше использовать amqp.
ruboss: судя по названию там хеш индекс, т.е. ключи будут не сортированными (в отличие от leveldb), хотя оно вам и не надо. Если бы все хранилось в RAM, то хеш индекс был бы быстрее. А т.к. данные (а может и часть индекса) сбрасывается на диск, то тут сильно влияет конкретная реализация, поэтому лучший способ - протестировать на ваших данных, и сравнить.
Вот ещё rocksdb от фейсбука, на основе leveldb, работает быстрее на железе с ssd.
> размер данных для одного хэша должен быть фиксированным?
Да
> если будет исключение в виде 1 кб (а не 100 байт), то придется все ячейки делать по максимально-возможному размеру
Нет, исключения можно обрабатывать отдельно.
> Если у вас в основном все документы размером в районе ~20байт, а только некоторые достигают 1кб, то можно установить размер каждой ячейки = 24б (тогда файл будет ~100Гб), а для тех что не влазят уже в отдельные файлы
Да просто, при ключе (инт 32) = 5, пишем по адресу 100х5=500, при ключе = 15, пишем в 100х15=1500 - как массив объектов.
Это самый просто способ, но при этом много "ячеек" могут быть не используемыми - "вхолостую" занимаемое место.
Зато это позволит не создавать отдельный hash/btree индекс который съест много RAM, (например avl-tree на C занимает ~50байт на элемент, т.е. 1млрд ключей требует ~50Гб памяти, хотя есть более экономные алгоритмы, в вашем случае больше подходит хеш таблица, т.к. сортировка ключей не нужна).
Далее можно применять разные хитрости по экономии места, например по принципу хеш таблицы.
Ещё если входные ключи в течении какого-то времени не далеко друг от друга, то можно все данные поделить на чанки и запаковать (сжиматься будет хорошо, в 10-30 раз).
Если у вас в основном все документы размером в районе ~20байт, а только некоторые достигают 1кб, то можно установить размер каждой ячейки = 24б (тогда файл будет ~100Гб), а для тех что не влазят уже в отдельные файлы.
В любом случае любые доработки для экономии места требуют усложнение алгоритмов, что-бы лучше подобрать вариант - нужно знать состав данных и тип их использования.
>В ангуляре дерти чекинг проверят изменились ли данные, в то время как в реакте идет поиск изменений
Это и есть dirty-checking, т.е. проход по всему дереву и сравнение старого и нового значения.
> для оптимизации разработчику придется задумываться
А в реакте разработчику нужно задумываться чтобы оно вообще заработало, навешивать ключи на дум, обруливать вставки от jQuery и ещё пачка всяких болячек. Не все там гладко как хотелось бы.
Лучше сказать, что react.js медленнее потому что его dity-checking медленнее чем ангуляровский.
>В целом же angular2 будет работать поверх виртуального DOM так что там все будет то же самое.
т.е. будет аналогичное (тормозное) вычисление дифф со своими багами?
Или только тот отдельный модуль который будет "подхватывать" дум только на старте?
Это btree индекс, "элементы" в нем размещаются без указания индекса, так что вариантов особо нет, да и по скорости это нормальный вариант.
Кстати какой индекс вы сделали, сортировка, фильтры в запросе есть?
Это хороший тон удалять "подписки", но в реальности оно зачастую не влияет, т.к. если директива удаляется то это значит что идет процесс разрушения scope, а при разрушении scope и DOM все подписки удаляются "автоматический".