Из-за декларативности компонент/шаблонов React выигрыш огромен. Вам не нужно определять все состояния компонента и переходы между ними. При увеличении сложности это значительно упрощает поддержку.
Вся суть React в декларативности шаблонов. Компонент при каждом изменении полностью перерисовывается (но виртуально), затем React вычисляет минимально дешевую мутацию состояний из А в Б. В императивном подходе все мутации состояний нужно определять руками. При увеличесии сложности компонента возрастает сложности определения всех состояний и переходов. Соответсвенно возрастает риск ошибки и сложность понимания.
Есть ли какие-то данные по тому какую память считает AWS Lambda: память занятая бинарем node + память занятая после запуска модуля или только память занятая модулем?
И еще есть ли данные по Startup latency: заводят ли они ноду с нуля каждый раз или реиспользуют пул процессов?
Просто нода сама по себе хорошо отъедает памяти и может долго стартовать.
LG 34UM95-P: IPS и 3440 x 1440 x 60Hz за $999 был уже где-то в середине прошлого года. Только как вы написали проблема в DisplayPort 1.2,1.3 и HDMI 1.4, которые есть только в топовых видеокартах и ноутах.
Например смешная ситуация с DisplayPort 1.1, который стоит сейчас почти в каждом более-менее свежем яблочном ноуте, с помощью которого можно подключить два 2560 x 1600 x 60Hz монитора, но нельзя один 3440 x 1440 x 60Hz… нужно либо развертку уменьшать либо разрешение.
Вопрос думать о зависимостях или нет. Если не использовать eval, то я могу гарантировать, что нет никаких подводных булыжников. Просто потыкайте в демку ;)
Короткий кэш из 5 итемов, к примеру, по ключу {format, timestamp[, locale]}. Lookup итема происходит без «Хэш-индекса» ака var index = {}; те просто for-ом по массиву, иначе будут тормоза с удалением добавлением итема в «индекс». Потом есть pointer который указывает в какую ячейку кэша нужно положит будущий результат. Всей этой структурой мы добиваемся того, чтобы не было GC на объектах кэша и не тратим время на конструирование составного ключа.
Большие кэши не нужны тк эта функция зависит от времени и каждый раз на вход могут подаваться разные знаения -> много промахов+тормоза.
var cache = [{
value: null,
format: null,
ts: null
}, ...];
var pointer = 0;
var ts = date.getTime();
// lookup
for (var i = 0; i < cache.length; t++) {
if (cache[i].format === format && cache[i].ts === ts) return cache[i].value;
}
// put
var value = strftime(format, date);
if (pointer > cache.length) pointer = 0;
cache[pointer].format = format;
cache[pointer].value = value;
cache[pointer].ts = ts;
pointer++;
return value;
Максимум выжал 21х без кэша — 3.3kk op/sec для %Y-%m-%dT%H:%M:%S%z. С FIFO кэшом x200 — 33kk op/sec. При 100% промахе кэша производительность деградирует до 18х.
Буст в 50 раз даже ручным кодом не удалось получить для паттерна выше. Для получения 50x без кэша/тредов точно не обойтись.
Я ответил вполне на конкретный вопрос: «Не могу понять, в чем разница между вашим кодом и моим?». Не знаю стало ли проще если я бы ответил, что в JS область видимости через var создает только функция, поэтому в следующем тике event loop значение переменной будет 3 и эта переменная будет общая для всех безымянных «замыканий» аргумента setTimeout.
jsbin.com/rimabu/3/edit?js
jsbin.com/ligawa/2/edit?js
Есть ли какие-то данные по тому какую память считает AWS Lambda: память занятая бинарем node + память занятая после запуска модуля или только память занятая модулем?
И еще есть ли данные по Startup latency: заводят ли они ноду с нуля каждый раз или реиспользуют пул процессов?
Просто нода сама по себе хорошо отъедает памяти и может долго стартовать.
Например смешная ситуация с DisplayPort 1.1, который стоит сейчас почти в каждом более-менее свежем яблочном ноуте, с помощью которого можно подключить два 2560 x 1600 x 60Hz монитора, но нельзя один 3440 x 1440 x 60Hz… нужно либо развертку уменьшать либо разрешение.
Close enough ;)
jsfiddle.net/m8kr4o8w/
if () {}
. Репозиторий же хранит полифилы в чистом виде (да это может смущать).var index = {};
те просто for-ом по массиву, иначе будут тормоза с удалением добавлением итема в «индекс». Потом есть pointer который указывает в какую ячейку кэша нужно положит будущий результат. Всей этой структурой мы добиваемся того, чтобы не было GC на объектах кэша и не тратим время на конструирование составного ключа.Большие кэши не нужны тк эта функция зависит от времени и каждый раз на вход могут подаваться разные знаения -> много промахов+тормоза.
%Y-%m-%dT%H:%M:%S%z
. С FIFO кэшом x200 — 33kk op/sec. При 100% промахе кэша производительность деградирует до 18х.Буст в 50 раз даже ручным кодом не удалось получить для паттерна выше. Для получения 50x без кэша/тредов точно не обойтись.
Заводилось в 1 ядро: Node v0.10.28 @ V8 3.14.5.9.