Collection – фреймворк для управления данными

[kobezzza]

var c= new Collection([ /* over 9000 */ ])
...
c.add({ name: 'bob', age: 18 })
...
var mature= c.get( ':el.age >= 18' )
var rich= c.get( ':el.salary >= 9000' )

1) .groupLinks(параметр, сохраняем индексы).get(делаем запрос по вторичным индексам). Т.е. чтобы юзать вторичные ключи, их нужно для начала создать, у тебя же это судя по всему делается сразу в конструкторе вызывая дополнительную не нужную нагрузку (и тормоза).

2) вопрос не про поисковые системы, а про твою мистическую супер-упер либу, поэтому опять ты слился.

[B~Vladi]

рассказывай

Гугли.

рискнёшь доказать полноту по тьюрингу?

Тебе нет.

ты так и не ответил на вопрос:

Я не знаю как так сгруппировать в Collection, поэтому примера не будет.

[kobezzza]

Я не знаю как так сгруппировать в Collection

Нужно сгруппировать людей по параметру старше/младше 18-ти?

// Вызываем метод group, и параметром указываем условие, в итоге создастся новая коллекция с ключами true и false, которые будут содержать результат группировки
.group(':el.age > 18')
// Старше 18
.get('true')
// Младше
.get('false')


// Можно делать ключи по более сложным условиям,
// т.к. ключи создаются по возвращаемому параметру условия,
// то можно создать множество ключей, например, с помощью тернарного оператора
// (разумеется можно писать простые функции или юзать разбиение на атомарные через стек)
.group(':el.age > 18 ? more18 : el.age < 12 ? less12 : less18')

[kobezzza]

Проводил замеры создания инстанса, 1 миллион итераций.
Вышло примерно так:
1) ИЕ 10 ~ 15 сек
2) FF 16 ~ 20 сек
3) Chrome 22 ~ 24 сек
4) Opera 12 ~ 50 сек

Начал оптимизировать логику конструктора:
1) Разложил if-ы по логической вложенности;
2) Заменил первичное копирование свойств с extend (рекурсивная реализация) на Object.create (с указанием прототипа, там где нет, написал свою реализацию).

Итого:
1) Opera 12 ~ 0.4 сек
2) Chrome 22 ~ 0.8 сек
3) IE 10 ~ 1 сек
4) FF 16 ~ 1.4 сек

Для теста на сафари 6 лень было мак брать (тем более его юзала мама ). Основные тормоза разумеется вызывала рекурсия.

PS: после оптимизации логика конструктора осталась идентичной.

[B~Vladi]

Основные тормоза разумеется вызывала рекурсия.

Естественно. Я всегда заменяю рекурсию на цикл, когда это возможно.

после оптимизации логика конструктора осталась идентичной.

Т.е. таки он по-прежнему возвращает экземпляры с разным набором свойств?

[kobezzza]

Естественно. Я всегда заменяю рекурсию на цикл, когда это возможно.

Рекурсия выглядит просто и лаконично, если не нужна сильная производительность, то я обычно оставляю всё как есть

Т.е. таки он по-прежнему возвращает экземпляры с разным набором свойств?

Ну, мб я не совсем тебя понял. Сейчас в общем всегда одинаковые свойства, но есть возможность изменить, указав второй параметр (по умолчанию это не делает), убрать можно, но мне не совсем понятно в чём профит? Скорость создания инстанса почти не увеличится (просто выкинется одно условие) или за ширмой что-то ещё?

[B~Vladi]

но мне не совсем понятно в чём профит? Скорость создания инстанса почти не увеличится (просто выкинется одно условие) или за ширмой что-то ещё?

В том то и дело, что кое-что "за ширмой" есть: http://habrahabr.ru/post/154537/, Пункт "Скрытые классы".

Вывод: объекты, созданные в конструкторах, всегда должны иметь одинаковый набор свойств и не менять этот набор в течении жизни программы. Производительность увеличивается на порядки. А если сделать вывод более общим - писать код нужно так, как если вы бы писали его на C++ или Java, касаемо объектов и их конструкторов.

[kobezzza]

В том то и дело, что кое-что "за ширмой" есть: http://habrahabr.ru/post/154537/, Пункт "Скрытые классы".

Вывод: объекты, созданные в конструкторах, всегда должны иметь одинаковый набор свойств и не менять этот набор в течении жизни программы. Производительность увеличивается на порядки. А если сделать вывод более общим - писать код нужно так, как если вы бы писали его на C++ или Java, касаемо объектов и их конструкторов.

О спасибо за ссылку, теперь всё стало ясно

[B~Vladi]

Рекурсия выглядит просто и лаконично

Да, и это искушает JS-программистов. forEach/map/reduse тоже выглядят просто и лаконично, но JS-движки не раскладывают их на циклы (по крайней мене V8 точно), поэтому производительность стремительно падает. Мы на маркете после замены forEach на for выиграли кучу времени для RPS. При том, что на сервере не V8, а движок от Mozilla (не уверен что это Rhino). Так что иногда стоит жертвовать читабельностью ради производительности. Тем более в библиотеках.

Мое имхо такое: библиотеки должны в первую очередь обеспечивать высокую производительность в ущерб читабельности. Яркий тому пример - jQuery.

[tenshi]

> .groupLinks(параметр, сохраняем индексы).get(делаем запрос по вторичным индексам).

это псевдокод. что конкретно туда писать?
в любом случае, похоже выборка будет O(n)

> у тебя же это судя по всему делается сразу в конструкторе вызывая дополнительную не нужную нагрузку (и тормоза)

зато при выборке не надо будет создавать индекс с нуля после каждого изменения состава коллекции, вызывая тем самым ещё большие тормоза.

> вопрос не про поисковые системы, а про твою мистическую супер-упер либу

она не супер и уж тем более не мистическая. она создаёт и поддерживает индексы, а также с их помощью поддерживается консистентность данных.

> Гугли.

что именно?

> Тебе нет.

почему?