Fork me on GitHub
#core-async
<
2017-10-10
>
rwilson04:10:50

@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.

rwilson04:10:06

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.

rwilson04:10:01

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)

rwilson04:10:53

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.

rwilson04:10:31

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.

jsa-aerial14:10:18

@rwilson I think you meant to ping @gowder - I was the one who suggested he look at #onyx.

rwilson18:10:18

Yep, sorry about that.