MB
По сравнению с CompletableFuture наверное
Size: a a a
2020 November 05
MB
Или лучше котлиновскими корутинами
ST
А, я забыл разленивить его
в общем случае не работает с ленивым мапом
но некоторые виды коллекций маппатся чанками (по 32 штуки разом), поэтому it depends
(time (->> (list 1 2 3)
(map #(future (Thread/sleep 1000) %))
(map deref)
(doall)))
"Elapsed time: 3023.0592 msecs"
=> (1 2 3)
(time (->> (vector 1 2 3)
(map #(future (Thread/sleep 1000) %))
(map deref)
(doall)))
"Elapsed time: 1011.2906 msecs"
=> (1 2 3)
но некоторые виды коллекций маппатся чанками (по 32 штуки разом), поэтому it depends
MB
в общем случае не работает с ленивым мапом
но некоторые виды коллекций маппатся чанками (по 32 штуки разом), поэтому it depends
(time (->> (list 1 2 3)
(map #(future (Thread/sleep 1000) %))
(map deref)
(doall)))
"Elapsed time: 3023.0592 msecs"
=> (1 2 3)
(time (->> (vector 1 2 3)
(map #(future (Thread/sleep 1000) %))
(map deref)
(doall)))
"Elapsed time: 1011.2906 msecs"
=> (1 2 3)
но некоторые виды коллекций маппатся чанками (по 32 штуки разом), поэтому it depends
Хмм, не очень понял, а почему разница тут?
MB
Мы же вроде форсим с помощью doall?
ST
Хмм, не очень понял, а почему разница тут?
ты же сам сказал, что знаешь, в чём косяк 😊
«Да, я понимаю, что запросы пойдут только тогда, когда я буду доставать)»
«Да, я понимаю, что запросы пойдут только тогда, когда я буду доставать)»
N
Меня больше интересует, как именно функциональный компонент получает информацию о состоянии при помощи хуков. До введения хуков - считалось, что поскольку у функциональных компонентов нет backing instance (переводится в российской литературе как "экземпляр поддержки", хранящего состояние компонента), то у него нет, как состояния, так и всех сущностей, связанных с жизненным циклом. Есть теория, что поскольку в любом случае есть компонент root, который вроде как классовый, то хук есть ни что иное как средство работы с состоянием экземпляра поддержки корневого классового компонента. Т.е. можно предположить, что хук есть:
а) в целом схожая по задумке с Redux штука (ограничение мест хранения состояния)
б) коррелирует с идеями, выраженными в Haskell - если работаешь с нечистыми функциями (побочные эффекты, состояние и т.д.), будь добр это делать в отдельном месте, в React - операции с пропсами должны быть написаны на pure functions
а) в целом схожая по задумке с Redux штука (ограничение мест хранения состояния)
б) коррелирует с идеями, выраженными в Haskell - если работаешь с нечистыми функциями (побочные эффекты, состояние и т.д.), будь добр это делать в отдельном месте, в React - операции с пропсами должны быть написаны на pure functions
Если я правильно понимаю, получает как из обычной переменной
MB
Ну, я был уверен, что doall зафорсит вычисление мапа
ST
ты же сам сказал, что знаешь, в чём косяк 😊
«Да, я понимаю, что запросы пойдут только тогда, когда я буду доставать)»
«Да, я понимаю, что запросы пойдут только тогда, когда я буду доставать)»
в листе future по одной запускаются после deref
в векторе запускается сразу несколько при обращении к первому элементу
в векторе запускается сразу несколько при обращении к первому элементу
ST
Ну, я был уверен, что doall зафорсит вычисление мапа
на порядок вычисления это не влияет
без doall нам time фигню вернёт, и результат начнёт вычисляться при отображении его в репле
без doall нам time фигню вернёт, и результат начнёт вычисляться при отображении его в репле
N
По сути хуки это и есть централизованное хранилище с довольно странным алгоритмом извлечения
Это точно?
MB
на порядок вычисления это не влияет
без doall нам time фигню вернёт, и результат начнёт вычисляться при отображении его в репле
без doall нам time фигню вернёт, и результат начнёт вычисляться при отображении его в репле
Т.е. в реальности они примерно одинаково должны отработать с doall?
ST
Т.е. в реальности они примерно одинаково должны отработать с doall?
не понимаю вопроса
я тебе показал код «из реальности»
я тебе показал код «из реальности»
MB
Ну да, я неправильно прочитал объяснение) Но я пока все равно не понял, почему из листа все замапится "по очереди"
MB
А, наверное теперь понял
MB
Придумают ленивость всякую блин
ST
Ну да, я неправильно прочитал объяснение) Но я пока все равно не понял, почему из листа все замапится "по очереди"
потому что «по одному»
тянем с конца, просим первый deref, он запускает первый get
второй deref, второй get
а с вектором сразу 32 первых get запускается параллельно, а deref их потом забирает без ожидания
тянем с конца, просим первый deref, он запускает первый get
второй deref, второй get
а с вектором сразу 32 первых get запускается параллельно, а deref их потом забирает без ожидания
ST
Придумают ленивость всякую блин
тогда в хаскеле тебе действительно тяжело должно быть 😊
MB
Ну вот и как идиоматично все сразу запустить?)
ST
потому что «по одному»
тянем с конца, просим первый deref, он запускает первый get
второй deref, второй get
а с вектором сразу 32 первых get запускается параллельно, а deref их потом забирает без ожидания
тянем с конца, просим первый deref, он запускает первый get
второй deref, второй get
а с вектором сразу 32 первых get запускается параллельно, а deref их потом забирает без ожидания
поэтому в моём варианте я написал mapv, чтобы наверняка