[Bf-committers] Blender and Asyncio

[Andreas Klostermann]

No, so far I haven't made precise and comprehensive performance
measurements. It just didn't come up as an issue. I was more interested in
getting it to work for my use cases and maybe get some other people
interested in what asyncio has to offer.

I know from personal experience and public benchmarks that aiohttp can
handle thousands of requests per second on a single core. I expect the
normal workload for my http-server addons to be at most one request per
second. Anything above that and we're talking about websockets, which are
even faster for every chunk transmitted. The idea is to do as little work
as possible and then let blender get on with its job.

Of course, the http-server addon can theoretically block the main loop for
a noticeable time. Like any other addon/operator/script. It's up to the
addon writer to mitigate this if necessary.

And yes, you said you'd want to make a better case for using asyncio vs
multi-threading, so I did at least try to make a case. If I understood you
incorrectly, I apologize.

Regards,
Andreas

On Tue, Mar 28, 2017 at 8:51 AM, Sybren A. Stüvel <sybren at stuvel.eu> wrote:

> On Mon, Mar 27, 2017 at 12:50:13PM +0200, Andreas Klostermann wrote:
> > No benefit to the end user. It's just for scripting pleasure. It
> > enables you to express a fairly complex workflow or even an
> > automated UI test with the convenient "async/await" syntax.
>
> So it makes it easy for developers to create complex situations for
> artists. This doesn't sound like an improvement to me.
>
> > I'm completely disinterested in the performance of the http server,
> > or anything run in asyncio for that matter. If the workload is 90%
> > asyncio/http and 10% blender, then it shouldn't be done inside
> > blender or distributed more wisely.
>
> Well, before putting anything into any program, IMO it is important to
> know how the new parts will perform and how these impact performance
> of existing parts of the software. You can only get a good feel for
> this by testing with real-life scenarios. This means loading up a
> production file (like a scene from Cosmos Laundromat), running through
> its animations, seeing the frame rate, and then performing HTTP
> queries and seeing the impact of those on the frame rate. Just a
> spinning Suzanne doesn't IMO constitute a proper performance test.
> Since you don't explain how you've tested the performance, this is
> still an open question.
>
> > Now, as to the question for why multi-threading is not such a good
> > idea here: multi-threading is really hard.
>
> I didn't ask that question; I was wondering whether you've actually
> measured performance differences, but I think you've also answered
> that question.
>
> Cheers,
> --
> Sybren A. Stüvel
>
> https://stuvelfoto.nl/
> https://stuvel.eu/
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
>