Если юзать matchMedia, то на каждый MQ будет по одному листенеру. Если setState дёргать из каждого, будет не очень.

Можно setState обернуть в дебаунс-аккумулятор и отправлять данные в setState сразу пачкой, каждые, допустим 200мс

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

Боже, зачем тут монга то))

А что не так?

Возьми redis

Если у тебя реально однотипные данные, то с ними в редисе можно прям очень быстро всё обрабатывать

если данные однотипные и поддаются индексации может быть строчные или колоночные базы лучше сработают?

редис разве в оперативку не упрется?

Упрётся, но это оптимизируемо

Попробую наверное ужать что возможно и редис

На самом деле у меня есть более смелые идеи, но там точно годы вычислений ?

Попробую, спасибо за совет

данные приводимы к нормализованному виду?

Можно setState обернуть в дебаунс-аккумулятор и отправлять данные в setState сразу пачкой, каждые, допустим 200мс

Вот-вот.

Почему не очень?

А я сейчас тестирую просто компонент. И считаю, сколько у него рендеров на один ресайз. И результат мне не очень нравится.

Там по сути 57 массивов данных, состоящих из объектов с одинаковыми ключами и значениями, значения всегда одного типа данных

А я сейчас тестирую просто компонент. И считаю, сколько у него рендеров на один ресайз. И результат мне не очень нравится.

ну явно надо отслеживать таймер и срабатывать через несколько раз

Но это базовый кейс, в целом в планах побольше, может до терабайта наберу

ты форекс анализируешь чтоли? :)

Форекс казино же, не

Но биржу, да ?

А я сейчас тестирую просто компонент. И считаю, сколько у него рендеров на один ресайз. И результат мне не очень нравится.

Ну вообще это нормальное поведение для объекта в dom

Надо смотреть не на число рендеров, а на вычислительные затраты)

А я сейчас тестирую просто компонент. И считаю, сколько у него рендеров на один ресайз. И результат мне не очень нравится.

Есть кейсы когда при ресайзе оставляют только контейнер без содержимого, а при жесткой экономии только рамка при ресайзе

Могу предложить неожиданную идею))

Делать throttle не по времени, а по координатам

Рывками же будет рендерится

А хотя и так рывки, да

Надо смотреть не на число рендеров, а на вычислительные затраты)

Я думаю, даже если будет оверхед на debounce (фантастика, мне кажется), то если обновляемый компонент будет содаржать большую структуру, то это скажется на производительности.

Реакту фиолетово должно быть на структуру

Делать throttle не по времени, а по координатам

Не-не. У меня не руками ресайз, а по медиазапросам.

Если это не так, то в архитектуре где--то проблемы и мутабельность

Реакту фиолетово должно быть на структуру

Хм. shouldComponentUpdate() тогда зачем?

Чтобы быстро решить костыли и косяки в проекте))

=))

Фигня в том, что лишь относительно немного программистов реально понимают, как работает реакт и его иммутабельость

Постоянные вызовы каррированных функций в рендере, а то и биндинги, ну и т.д.

Ну, за иммутабельностью же ты следишь, а не реакт.

ты форекс анализируешь чтоли? :)

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

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

так-что надо как-то исхитряться в пределах одной машины молотить. сколько там современные процы с мамками позволяют вкорячить оперативы? раньше 32 гб лимит был, сейчас не буду врать, но вроде 128 стало?

ну и не факт что JS все же. может быть что-то более низкоуровневое?

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

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

ну тогда полюбому кластер

ну и не факт что JS все же. может быть что-то более низкоуровневое?

Уже задумываюсь об этом давно ?

Apache Ignite

Тоже вариант ?

Под ноду правда смотрю из коробки нет

Ну понятно в целом - условия требуют полностью пересмотреть мою аналитическую софтину

рефакторинг рулит :)

а тотальный рефакторинг так и тем более :)

Там на самом деле строк не так много. Правда вот 100500 переменных одновременно и они всё прибывают и прибывают с каждой идеей. И 100500 итераций рассчетов.

Тебе б SIMD

А лучше GPU

Вот про это сегодня думал

Но GPU я пока не умею

И ещё не знаю как уметь

В общем всем спасибо, есть о чем подумать

вообще это натуральная бигдата. в одного ее пилить это конечно героизьм :)

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

Я работал над проектом(с рекламой связанным) где нужно было каждый день обрабатывать порядка 10гб данных, это не 114 конечно, но порядок близкий. Помимо кучи оптимизаций(кстати вместо редиса там еще memcached использовался, корни проекта уходят довольно далеко в прошлое) - основой решения был амазон. По сути вся архитектура системы была построена на амазоне. В нужный момент просто подымался кластер из пары десятков машин, которые за около часа обрабатывали данные и самоустранялись. Тут конечно серьезный вопрос в том, насколько данные годятся для паралеллизма. И насколько сложные вычисления. Допустим в том, чем я занимался - все было достаточно просто. Если вычисления реально сложные и их можно без проблем делать паралелльно - имеет смысл задуматься над opencl, как выше советовали(GPU тобишь). Но если с этим опыта нет, то я б начал с паралеллизма и кластера.

И Golang :)

Поясните мне с вертухи, ангуляр первый хорошо или нет? Или лучше переписать на второй?

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

Поясните мне с вертухи, ангуляр первый хорошо или нет? Или лучше переписать на второй?

Первый ангуляр — это максимальная доза ебанины, наверное что угодно лучше чем первый ангуляр

Первый ангуляр — это максимальная доза ебанины, наверное что угодно лучше чем первый ангуляр

Чому? И вообще, сколько не прочитал статей, но так и не понял нахуй он нужен и почему второй лучше чем первый. Последний раз писал фронт лет 6 назад, да.

Ну а вот это уже хуже. Изучать всё равно придётся

ERROR: S client not available

Оптимальным сейчас является реакт и экосистема вокруг него, но что-то мне подсказвает что твоим возмущением можно будет отапливать дома?

Ладно, тогда такой вопрос. А что есть такого, чтобы вот современное, но без жопной боли?

Вообще не ебу во что превратился текущий веб, ведь всё то что делают какие-то там ебаные фреймворки делал раньше на чистом жс. Какого хуя происходитблядьпиздец.

?

Несмищно, я уже третий раз открываю и закрываю сайт реакта.

Тоже так было. Но пришлось заставить себя выучить.

Из-за того что интерактив на жквери получался через одно место

http://www.material-ui.com/ Годнота или нахуй?

сейчас все дрочат на реакт и плотно, кружком прям

сейчас все дрочат на реакт и плотно, кружком прям

Странные у вас там развлечения

Тимбилдинг?))

Больше похоже на коворкинг.

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

Тимбилдинг?))

фронтенд

фортенд

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

https://habrahabr.ru/post/315466/

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

с оф доков, поставить npm и create-react-app

с оф доков, поставить npm и create-react-app

>поставить npm А вот без этой хуйни можно?

>поставить npm А вот без этой хуйни можно?

скачать как бутстпар чель хочешь?

Короче, ебал я в рот это говно.Доделаю всё на первом, всё, а потом найму макаку, как только профит будет.

Горю, блядь, спасите.

как во фронте ты без нпм жил лол?

>поставить npm А вот без этой хуйни можно?

Так это обычный менеджер зависимостей. Счас у всех языков он есть.

Ему просто было важно уточнить, что он то — Бэкендер, а мы тут все скругления в фотошопе рисуем

вообще странно, что за бекенд больше платят

одна только верстка сколько нервов съедает

вообще странно, что за бекенд больше платят

так и не платят

разве?

Во во)

по крайней мере, верстка точно сильно недооценена

разве?

Ну ты небось с тимлидской зп сразу сравниваешь)

у бекэнда ответственности больше