[Python-ideas] POPT (Python Ob ject Provider Threads)

[Steven D'Aprano]

On Tue, Jun 19, 2018 at 04:47:46PM +0200, Martin Bammer wrote:

> And here comes the idea for POPT. With this idea the Python interpreter has
> running several threads in background (1 thread for each object type) 

The builtins alone has 47 exception types. I hope you don't mean that 
each of those gets its own thread.

Then there are builtins:

    str, bytes, int, float, set, frozenset, list, tuple, dict,
    type, bytearray, property, staticmethod, classmethod, 
    range objects, zip objects, filter objects, slice objects,
    map objects, MethodType, FunctionType, ModuleType

and probably more I forgot. That's 20 threads there. Don't forget things 
like code objects, DictProxies, BuiltinMethodOrFunction, etc.

When I run threaded code on my computer, I find that about 6 or 8 
threads is optimal, and more than that and the code slows down. You want 
to use 25-30 threads just for memory management. Why do you hate me? 

*wink*


> which
> manage a set of objects as an object cache. Each object in the cache is
> already preconfigured by the object provider thread. So only the part of
> the object structure which is individual has to be initialized.

For many objects, wouldn't that be close enough to "all of it"? (Apart 
from a couple of fields which never change.)


> This saves a lot of processing time for the main thread 

Do you know this for a fact or are you just hoping?


> and the memory management has
> much less to do, because temporarily unused objects can be reused
> immediately.

Or, unused objects can sit around for a long, long time, locking up 
memory in a cache that would be better allocated towards *used* objects.


> Another advantage is that every Python code uses several CPU cores in
> parallel, even if it is a single threaded application, without the need to
> change the Python code.

How do you synchronise these threaded calls? Suppose I write this:

    x = (3.5, 4.5, "a", "b", {}, [], 1234567890, b"abcd", "c", 5.5)

That has to syncronise 10 pieces of output from six threads before it 
can construct the tuple. How much overhead does that have?

> If this idea is well implemented I expect a big performance improvement for
> all Python applications.

What are your reasons for this expectation? Do other interpreters do 
this? Have you tried an implementation and got promising results?


-- 
Steve