This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-10
Channels
- # aleph (4)
- # beginners (32)
- # cider (12)
- # cljs-dev (56)
- # cljsrn (7)
- # clojars (3)
- # clojure (165)
- # clojure-dev (33)
- # clojure-germany (1)
- # clojure-italy (27)
- # clojure-russia (7)
- # clojure-spec (24)
- # clojure-uk (62)
- # clojurescript (37)
- # core-async (7)
- # core-matrix (1)
- # cursive (9)
- # data-science (8)
- # datomic (8)
- # duct (4)
- # events (1)
- # figwheel (7)
- # flambo (3)
- # fulcro (43)
- # hoplon (25)
- # jobs-discuss (8)
- # lein-figwheel (4)
- # luminus (2)
- # off-topic (35)
- # om (8)
- # om-next (3)
- # onyx (30)
- # pedestal (62)
- # portkey (2)
- # protorepl (2)
- # re-frame (40)
- # reagent (9)
- # shadow-cljs (123)
- # specter (30)
- # sql (22)
- # testing (1)
- # uncomplicate (40)
- # unrepl (3)
- # vim (13)
- # yada (5)
@gowder my suspicion is that if maximizing your cpu & io, that memory won’t be an issue with that type of problem. Unless, as you said, the images turn out to be pathologically huge.
The interesting part will be balancing it such that you keep each scaling / io thread busy, without waiting for the result of the previous step. And that will have to be tuned to the available cores and disk i/o.
If one task gets ahead of another, that’s when your memory consumption will grow (e.g. images read but not scaled, scaled but not written)
You can easily back pressure tasks with appropriate chan buffer sizes, though. Such that a particular task cannot produce too much more than the next task is ready for.
Personally, #onyx feels like overkill for your task. But, admittedly, I had a 10K+ events/sec stream processing with real-time visibility problem and I still looked an onyx and got scared away. So, take that as you will.
@rwilson I think you meant to ping @gowder - I was the one who suggested he look at #onyx.