TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #654 · 16.11

Пытаюсь решить организационно-логистическую задачу в #Satisfactory. Может быть, умные люди (вы) мне дадите интересные советы. Я уже открыл практически все типы деталей, они довольно сложные, и для производства многих из них нужны целые цепочки: добыть ресурс А в одном месте и ресурс B в другом, потом сделать из них детали C и D, из этой пары получить деталь E, добыть ещё ресурс F, соединить, смешать с водой... В каком-то месте эти цепочки удобно разрывать (то есть не строить всё на одной фабрике, а растаскивать фабрики по карте). Потому что, во-первых, с гигантской базой, производящей все типы всех деталей, банально неудобно работать. Во-вторых, её тяжело масштабировать. Хотя у этого решения есть плюсы, и некоторые так делают, лично я идти по такому пути не хочу. Но в каком месте рвать цепочки? Глобально есть две крайности: 1. Можно делать по фабрике на каждое звено производства. Например, фабрика, которая делает деталь E, должна принимать на вход детали C и D, и всё. Такая схема очень легко масштабируется: небольшую фабрику очень просто расширять. А детали возить между фабриками поездами. Но тогда потребуется типа 100 разных фабрик и очень сложная железнодорожная сеть. 2. Можно в каждую фабрику привозить сырьё. Только то, что невозможно произвести, а можно только добыть. Фабрика делает с нуля из сырья все детали, в том числе для промежуточных звеньев. Такую схему очень легко балансировать: один раз посчитал, сколько нужно сырья, и всё. Но фабрики для сложных деталей будут громоздкие. А ещё если деталь C нужна в десяти местах то придётся десять раз повторить всю цепочку производства детали C, а можно было бы в одном месте делать очень много деталей C и возить. Мне не нравятся оба варианта, значит, рвать цепочку нужно где-то посередине. Но где? #games

Резултати

Намерени 3 подобни публикации

Търсене: #gevent

当前筛选 #gevent清除筛选
djangoproject

@djangoproject · Post #439 · 13.09.2017 г., 03:57

Evented Django part one: Socket.IO and gevent #Socket.IO was developed with a #Node.JS server implementation, but work is being done to add server implementations to a variety of languages. Two such servers exist for Python, tornadio and #gevent-socketio. I'm a big fan of gevent, so I will use gevent-socketio, but tornadio looks well-written and very promising. http://codysoyland.com/2011/feb/6/evented-django-part-one-socketio-and-gevent/

djangoproject

@djangoproject · Post #170 · 22.09.2016 г., 14:27

https://pypi.python.org/pypi/uvloop #uvloop is a fast, drop-in replacement of the built-in #asyncio event loop. uvloop is released under the MIT license. uvloop and asyncio, combined with the power of async/await in Python 3.5, makes it easier than ever to write high-performance #networking code in Python. uvloop makes asyncio fast. In fact, it is at least 2x faster than #nodejs, #gevent, as well as any other Python #asynchronous framework. The performance of uvloop-based asyncio is close to that of Go programs.

djangoproject

@djangoproject · Post #270 · 26.02.2017 г., 08:08

https://www.obeythetestinggoat.com/testing-async-asyncio-and-performance.html #Testing, #async, #asyncio, and #performance Sun 27 December 2015 By Harry I recently did some experimenting with asyncio, and wanted to report back on how I got on with writing tests for it. While I was at it I was also able to compare its performance with a couple of other approaches to #mutlitasking in Python, namely #threads and #gevent, so I'll report on that here too. (tl;dr: it's much of a muchness).