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

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

Гугли.

Тебе нет.

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

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

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


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

Проводил замеры создания инстанса, 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: после оптимизации логика конструктора осталась идентичной.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Гугли.

что именно?

> Тебе нет.

почему?