@JSlang

Страница 537 из 2237
 
Stepan
10.01.2017
06:05:56
Почему?

 
Oleg
10.01.2017
06:06:02
Примерно через 10000, в зависимости от настроек, приложение упадет

 
Konstantin
10.01.2017
06:06:15
не падает, работает непрерывно сутками

 
Oleg
10.01.2017
06:06:16
Переполнится стек

Google
 
Konstantin
10.01.2017
06:06:23
и утечек нет

 
Oleg
10.01.2017
06:06:26
Значит не совсем рекурсия там

 
А, с таймаутом то

 
Тогда не рекурсия

 
И поэтому работает

 
Konstantin
10.01.2017
06:07:17
почему не рекурсия? вызов функции из самой себя

 
Oleg
10.01.2017
06:07:30
Вызов функции из таймаута

 
?

 
Konstantin
10.01.2017
06:08:06
а

 
Oleg
10.01.2017
06:08:06
А таймаут в 0?

 
Или значение?

 
А если значение, то почему?

 
Konstantin
10.01.2017
06:08:31
значение

Google
 
Konstantin
10.01.2017
06:08:48
там высчитывается время выполнения запроса чтобы данные менялись раз в секунду в браузере

 
Oleg
10.01.2017
06:08:57
Тогда ок

 
Константин
10.01.2017
06:09:21
а если будет 0, то что?

 
Oleg
10.01.2017
06:09:46
То тогда имеет смысл юзать process.nextTick, если нода, оное лучше почистит память

 
Константин
10.01.2017
06:12:56
а что с памятью будет?не до конца понимаю

 
Oleg
10.01.2017
06:14:40
Сборщик мусора лучше уберет мусор т.к. это почти явный его вызов, при этом оное эквивалентно тому что будет если вызвать setTimeout с 0

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

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

 
Константин
10.01.2017
06:19:04
про последнее знал, за остальное спасибо)

 
Oleg
10.01.2017
06:20:10
?

 
hlomzik
10.01.2017
06:23:56
setImmediate еще есть

 
Oleg
10.01.2017
06:24:13
Ага, только не везде

 
На столько не везде что только в IE и Edge

 
То есть только у Микрософта

 
Константин
10.01.2017
06:26:22
как раз этот метод и работает сразу же

 
Oleg
10.01.2017
06:28:07
Ладно, не буду тут шуток шутить ?

 
Дмитрий
10.01.2017
06:41:04
В асинхронной модели её просто нет
Ой ли))

 
Oleg
10.01.2017
06:41:27
Ой ли))
А я там ниже написал кейс

 
Внешний мир может быть суров

 
Дмитрий
10.01.2017
06:42:26
Нет, именно внутри приложения

Google
 
Дмитрий
10.01.2017
06:43:11
Ничто не мешает кривым рукам устроить гонку потоков на промисах

 
Oleg
10.01.2017
06:43:32
Или сделать бесконечный цикл

 
Ну тут увы, архитекрура не поможет ?

 
Dima
10.01.2017
06:49:28
Ну а если прям совсем не влезает в одно ядро, а невлезать оно может только если в рамках одного процесса нужно что-то там сложное посчитать и у нас нет расшаренной БД, нужно хранить стейт в переменный и прочее такое - то тогда да, увы, нужно резать алгоритм на части и параллелить его руками между инстансами ноды по одному кусочку на каждое ядро. Или делать конвеер с обменом. Всё зависит от алгоритма. Но если оно так - либо сервер слабоват выбран, либо нода уже не подходит для этой задачи.
спасибо

 
Сборщик мусора лучше уберет мусор т.к. это почти явный его вызов, при этом оное эквивалентно тому что будет если вызвать setTimeout с 0
а почему setTimout с 0 - позволяет другим "процессам" выполняться? ведь 0 это и есть 0 ничего не ждем.

 
Oleg
10.01.2017
06:51:19
А оно всё-равно кидает в очередь

 
И продолжает выполнение того кода что есть, а когда завершает - только тогда смотрит очередь

 
Dima
10.01.2017
06:51:52
А оно всё-равно кидает в очередь
я помню какую-то лекцию, о том что в JS есть некций стек, куда закладываются все действия. и они по очереди выоплняются

 
так смутно несколько лет назаж посмотрел бегом

 
Oleg
10.01.2017
06:52:04
Это, к слову, хороший способ кинуть что-то в конец очереди исполнения

 
Dima
10.01.2017
06:53:28
Это, к слову, хороший способ кинуть что-то в конец очереди исполнения
как на английском языке называется эта сущность в базсе жаваскритпа: очередь стек. чтоб о ней можно было почитать через гугл

 
Oleg
10.01.2017
06:56:10
Да так же как и везде

 
Arseniy
10.01.2017
06:58:32
Примерно через 10000, в зависимости от настроек, приложение упадет
А JS не оптимизирует на уровне байткода такие конструкции? Все таки будет переполнение стека?

 
Дмитрий
10.01.2017
06:58:39
И продолжает выполнение того кода что есть, а когда завершает - только тогда смотрит очередь
Реальный timeout 0 существует только в ноде, кстати

 
В браузере минимум 12 мс

 
Andrey
10.01.2017
06:59:29
как на английском языке называется эта сущность в базсе жаваскритпа: очередь стек. чтоб о ней можно было почитать через гугл
посмотри на эту тему https://www.youtube.com/watch?v=8aGhZQkoFbQ

 
Oleg
10.01.2017
06:59:54
А JS не оптимизирует на уровне байткода такие конструкции? Все таки будет переполнение стека?
Есть такие понятия как хвостовая рекурсия, ну и древовидная. Не смотря на то что это заложено в стандарт ES6 - до сих пор не реализовали. А до ES6 вообще не говорилось об этом.

 
В браузере минимум 12 мс
А ещё может от питания ноутбука зависеть ?

 
Wilfred
10.01.2017
07:00:58
как на английском языке называется эта сущность в базсе жаваскритпа: очередь стек. чтоб о ней можно было почитать через гугл
queue - очередь, stack - стек, heap-куча

 
Dima
10.01.2017
07:01:01
посмотри на эту тему https://www.youtube.com/watch?v=8aGhZQkoFbQ
спасибо

Google
 
Дмитрий
10.01.2017
07:01:33
А ещё может от питания ноутбука зависеть ?
Не важно, по спеке минимум 12

 
Oleg
10.01.2017
07:01:47
Мир суров

 
Дмитрий
10.01.2017
07:01:55
Ога

 
Oleg
10.01.2017
07:02:01
Не все согласуют спеку, увы

 
Дмитрий
10.01.2017
07:02:10
Браузеры — все

 
Oleg
10.01.2017
07:02:19
А вот про рекурсии конечно странно что так и не внедрили

 
Оптимизацию

 
Dima
10.01.2017
07:04:02
Да так же как и везде
вот как это называется: https://developer.mozilla.org/en/docs/Web/JavaScript/EventLoop

 
event loop

Admin
ERROR: S client not available

 
Oleg
10.01.2017
07:05:40
Да

 
Дмитрий
10.01.2017
07:10:07
Есть такие понятия как хвостовая рекурсия, ну и древовидная. Не смотря на то что это заложено в стандарт ES6 - до сих пор не реализовали. А до ES6 вообще не говорилось об этом.
Вообще кстати js ряд оптимизаций таки делает

 
Но своеобразных

 
Dreamerinnoise
10.01.2017
07:10:39
https://twitter.com/horse_js/status/818666826888572928

 
Дмитрий
10.01.2017
07:10:52
Я когда добивался ультра скорости pipe / compose ловил значительный буст от вычисления функций прямо перед возвратом

 
типа какая-то фигня там оптимизируется

 
Я даже сформулировать это толком не могу >_<

 
Oleg
10.01.2017
07:13:13
Тут уже исходники движков копать нужно

 
Да

 
Ivan
10.01.2017
07:14:35
https://www.youtube.com/watch?v=HPFARivHJRY

Google
 
Ivan
10.01.2017
07:14:56
вроде в этом докладе видел что-то по этому поводу

 
Andrey
10.01.2017
07:27:18
Я когда добивался ультра скорости pipe / compose ловил значительный буст от вычисления функций прямо перед возвратом
Есть проект на гитхабе или gist с бенчмарком?

 
Тоже интересно посмотреть, что было сделанно и дало эффект

 
Дмитрий
10.01.2017
07:29:37
Есть проект на гитхабе или gist с бенчмарком?
Ну в итоге пришёл к тому, что проще вообще все вычисления развернуть

 
А своя реализацая array-flatten даже с этими оптимизациями оказалась медленнее модуля array-flatten

 
В итоге модуль оказывается в разы быстрее ramda.compose и redux compose при том что они без уплощения аргументов)

 
https://github.com/zerobias/pipe-perf

 
Сейчас там бенчмарк выдаёт проценты результатов разных модулей от самого эффективного решения, но только недавно догадался как можно сделать оптимальный бенч — надо от развернутого пайпа проценты и считать) Думаю на следующих выходных добью

 
Konstantin
10.01.2017
07:36:35
Ничто не мешает кривым рукам устроить гонку потоков на промисах
у меня кстати там промисы и есть)

 
https://i.gyazo.com/9d049718af603f46244ab785c2657bd9.png

 
Andrey
10.01.2017
07:39:49
https://github.com/zerobias/pipe-perf
спасибо, посмотрю и много ты накрутил над benchmark)

 
Дмитрий
10.01.2017
07:41:57
спасибо, посмотрю и много ты накрутил над benchmark)
Ну вообщ хочется в конце концов доделать до уровня фреймворка - воткнул тесты - получил процентное сравнение на правильно сгенерированных данных, среднее, медиану и доверительный интервал 0.95 ??

 
Andrey
10.01.2017
07:43:51
Да, отличная идея) Нужно еще сделать проверку выходных результатов, что все вернут одинаковое значение

 
или я этого не нашел просто)

 
а так, у меня стандартный бенчмарк выглядит так https://gist.github.com/Tom910/41e6f150bc6d1325ebe75f6fe04245bf

 
Дмитрий
10.01.2017
07:45:01
Все сравнить точно не получится, benchmark.js пару миллионов тестов вроде бы прогоняет ? Я там небольшой блок smoke test сделал, чтобы видеть какие результаты на самом деле возвращаются

 
Andrey
10.01.2017
07:46:01
не, только один вызов проверять, не все

 
Дмитрий
10.01.2017
07:46:35
А, ну так да

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

 
Andrey
10.01.2017
07:48:47
запускать в отдельной ноде?

 
тогда можно сделать 2 теста, в прогретом состоянии и только холодном

 
Дмитрий
10.01.2017
07:49:55
запускать в отдельной ноде?
Я каждому испытуемому просто выдаю уникальные данные, так надёжнее

Страница 537 из 2237