Collection v5

[kobezzza]

Выпустил апдейт 5.0.4. Значительно увеличена скорость работы pop / shift для простых объектов.

[kobezzza]

Выпустил апдейт 5.0.5.

Реализовано кеширование сгенерированных циклов в файле для node.js.
Реализована оптимизация "холостых" итераций, т.е. без передачи параметров в callback.

$C({a: 1, b: 2}).forEach(function () {
    ...
});

$C({a: 1, b: 2}).forEach(function (el) {
    ...
});

Первый вариант теперь работает почти в 3 раза быстрее.

[melky]

$C({a: 1, b: 2}).forEach(function () {
    ...
});

$C({a: 1, b: 2}).forEach(function (el) {
    ...
});

почему работает эта оптимизация???

[kobezzza]

почему работает эта оптимизация???

Потому что el вычисляемый параметр, и в некоторых случаях довольно затратный (получение из цепочки прототипов и т.д.). На самом деле я просто добавил условие, что неиспользуемые параметры не только не передаются в callback, но и не вычисляются и это дало профит.

Конечно это оптимизация нужна очень редко, но все равно

[kobezzza]

Сегодня приснился ещё один оптимизационный трюк, думаю смогу ускорить работы некоторых операций ещё процентов на 5-10

[melky]

не сравнивал скорость работы $C с fast.js?

[kobezzza]

не сравнивал скорость работы $C с fast.js?

Нет, но как раз собирался, но почти уверен, что Collection порвёт всех как тузик грелку

А если сравнивать с точки зрения алгоритмической сложности, тот тут Collection быстрее всех аналогов в N раз (где N количество операций), например:

filter1().filter2().map().slice(0, 10) // 4 операции + на slice потенциальный огромный оверхед

$C(...).map(calback, {filter: 'filter1 && filter2', from: 0, count: 10}) // никаких оверхедов, т.к. всё делается в один проход и операция сбросится после достижения count: 10

UPD: в релизе 5.1 (надеюсь сегодня сделаю) реализовал бешеную оптимизацию для обхода Map / Set. При сравнении с нативным for of разница примерно в 40 раз, а при обходе с reverse: true, то в N раз (где N - количество элементов в коллекции).

UPD:UPD:
Глянул код fast.js, результат мне уже известен Вообще все классические оптимизации, которые применяются в underscore, lodash, fast.js и т.д. по природе своей ущербны, т.к. они их делают в живом цикле и поэтому они всегда будут проигрывать Collection или нативным циклам. А вот Collection основан на хитрой кодогенерации, т.е. полученный цикл лишён не нужных для каждого конкретного случая оптимизаций и проверок и поэтому работает с максимальной эффективностью.

[kobezzza]

Выпустил апдейт v5.1.0.

1) Исправлена критическая бага в методе remove;
2) Очень сильно увеличена производительность обхода Map / Set коллекций;
3) Улучшен модуль инлайнинга, что дало в некоторых случаях дополнительный профит;
4) Добавлена новая сборка Collection.core, которая включает в себя только 2 основных метода: forEach и extend и весит примерно 8кб в gzip;
5) Добавлен параметр chain для некоторых итерационных методов, который позволяет делать цепочки вызовов:

$C(...).map(..., {chain: true}).get()

[kobezzza]

В планируемом обновление 5.2.0 добавлю новый контекстный метод yield (будет требоваться поддержка генераторов).

var result = $C({ ...очень большой объект... }).map(function (el, key, data, i) {
    this.$.i = this.$.i || 1;

    if (i === 1e6 * this.$.i) {
        this.$.i++;
        this.yield();
    }
});

$C.onFinish(result, function (value) {
    ...
});

Т.е. метод this.yield(); прерывает выполнение операции и возвращает объект:

{
    done: true / false,
    result: ...
}

Таким образом дробление сложной операции будет осуществляться очень просто. Работу над обновлением планирую начать сразу же, после окончания работа над Snakeskin 4.

[kobezzza]

Также решил добавить 2 новых параметра для всех итеративных методов: iterations и onFinish

$C({ ...очень большой объект... }).forEach(function () { ... }, {
    iterations: 1e5,
    onFinish: function (value) { ... }
});

Т.е. каждые 1e5 итераций будет делаться прерывание и дальнейшая работа продолжиться на следующем итерационном цикле, а onFinish будет вызван, когда операция закончиться.