так в очереди же столько же объектов будет

Получать частями

И вычислять на ходу

Взял один элемент и произвел вычисления вместе с ранее вычисленными

так я в дочернем процессе всё буду делать, мне главное, чтобы он out of memory не кинул

Разбирай на части

Может кинуть

От оси зависит

быстрее через бд будет, в нее перегнать и птом и там группировать и вытаскивать по кускам в процессе рендеринга

не, там математики много :)

бд не осилит :)

бд и так есть

буду кусочками вытаскивать, значит

Так, а распараллелить обход массива? Разбить на несколько подмассивов? Обходить кусками и тд. Ну, из очевидного)

а если вогнать результат вычислений в бд

там же не реал тайм?

даже если реал тайм можно переодически переписывать данные птом сигнал на рендер посылать

не, там математики много :)

Кстати, посмотри на лодаш, там есть методы работы с массивов, типо вычислить среднее, исключить не найденное и т. д.

это уже на нативном сделано

Так, а распараллелить обход массива? Разбить на несколько подмассивов? Обходить кусками и тд. Ну, из очевидного)

типа да

Кстати, посмотри на лодаш, там есть методы работы с массивов, типо вычислить среднее, исключить не найденное и т. д.

lodash/ramda

а вообще стримами будет проще всего, особенно если из сети получаешь данные (Rx, Kefir)

обрабатывать по мере получения

как думаете, js не поперхнется массивом из 1 695 743 строк?

Попробуй использовать Связку promises +lodash

ну...из базы вытащил, вроде даже спокойно, больше 1.5гб не сожрало на 1.6кк значений

но всё равно разбивку сделаю, по 500к, наверно

используй для перебора массива Promise.all(map.someArray(function(){}))

а чём мне промайз поможет? :)

используй для перебора массива Promise.all(map.someArray(function(){}))

оч хреново для arr.length === 1000000

но всё равно разбивку сделаю, по 500к, наверно

чем меньше пачка, тем быстрее работать будет

в твоем случае идеал, наверное, 10-100К

но я тогда потрачу время на обращение к базе

во первых промис до завершения не позволит остальному коду что то делать в о вторых почитай https://habrahabr.ru/company/mailru/blog/269465/

во первых промис до завершения не позволит остальному коду что то делать в о вторых почитай https://habrahabr.ru/company/mailru/blog/269465/

не позволит :)

на таком количестве

плюс цепочки промисов

ты попробуй

во первых промис до завершения не позволит остальному коду что то делать в о вторых почитай https://habrahabr.ru/company/mailru/blog/269465/

только если освободится поток исполнения

уже было :)

ты попробуй

изучи стандарт ecmascript

все плохо?

стек забивается

все плохо?

синхронные операции блокируют поток, и промисы вообще никакой погоды не сделают только увеличат память

обход массива это как раз синхронная операция

промис даже на 100к все вешает

я не настаиваю но массив можно перебрать лодашевским фор.ичем он с этим справляется + куча плющек на поиск и выбоку нужных элементов массива

плюс лодашевкая Math

нативное явно быстрее лодаша будет :)

нативное явно быстрее лодаша будет :)

+

особенно, если не юзать всякие forEach, а старый добрый for

не всегда нативно forEach для перебора массива не используешь к тому же var someVal = someArray.filter('someVAl'...) не сможешь использовать

все эти forEach, map, reduce, filter это обертка над for'ом

не всегда нативно forEach для перебора массива не используешь к тому же var someVal = someArray.filter('someVAl'...) не сможешь использовать

дублировать массив из 100К элементов прям крутая затея

быстрее это всё в одном цикле сделать

все эти forEach, map, reduce, filter это обертка над for'ом

mac и reduce под капотом имеют нативную реализацию (в v8)

ну ок

Как вариант можно чистить память для всех элементов внутри цикла, те For(i=0;i<len;i++){ let v=...; v=null;}

Может памяти будет меньше жрать

нативное явно быстрее лодаша будет :)

если просто перебирать каждый i'ный элемент, то да. А если нужны какие-то сложные операции с масивом, то лодаш лучше справиться, там внутри работают алгоритмы, которые могут решают задачу, даже не перебрав весь массив

sequelize можно заставить запихать Station в отдельный объект?

чтобы можно было обращаться item.Station.id

Все поля по по которым будут сравнения вынеси в поля таблицы, раскидывай их

шта

Птом повесь индекс на поля которые с помощь === будут сравниватся http://docs.sequelizejs.com/manual/tutorial/models-definition.html#indexes

Вынеси в отдельное поле

чтобы можно было обращаться item.Station.id

При заполнении раскидай все такие которые во вложенной структуе

чёт ниче не понял, как мне индексы помогут в этом

Ну ты в каком месте хочешь до вложенного объекта стучаться?

Если в условии для фильтрации то индекс должен помощь, если для рендора то не сильно поможет

это индекс для базы

причем он тут

во всех челочеческих ORM все связи пихаются в отдельные объекты, должно быть: { Station: { id: 1, name: ... ... } compF: ... ... }

а не то что sequelize сделал

Ну я про оптимизацию говорю

ставить индексы я умею, спасибо :)

я спрашиваю как в результате выборки сделать, чтобы Station, который джойнится был в отдельном объекте, чтобы в цикле потом обращаться item.Station.id, а не item['Station.id']

Ну где юзается переменная?

Условие или рендер

причем тут цикл