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/
signature.asc
Description: PGP signature
_______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
