[Bf-committers] Blender and Asyncio

[Sybren A. Stüvel]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-committers/attachments/20170328/568aa4af/attachment.pgp