Copy-on-write friendly Python garbage collection (Posting On Python-List Prohibited)

Ned Batchelder ned at nedbatchelder.com
Mon Jan 1 15:54:07 EST 2018


On 1/1/18 1:49 PM, Niles Rogoff wrote:
> On Mon, 01 Jan 2018 10:42:58 -0800, breamoreboy wrote:
>
>> On Monday, January 1, 2018 at 10:14:59 AM UTC, wxjm... at gmail.com wrote:
>>> Le lundi 1 janvier 2018 08:35:53 UTC+1, Lawrence D’Oliveiro a écrit :
>>>> On Monday, January 1, 2018 at 7:52:48 AM UTC+13, Paul Rubin wrote:
>>>>> I wonder if things would suffer if they tried a more aggressive
>>>>> approach and ditched refcounting completely.
>>>> One thing that would suffer is Python’s well-behaved memory usage.
>>>> You would need to start imposing heap usage limits, like you do in
>>>> Java.
>>> Memory:
>>>
>>>>>> sys.getsizeof('abcdefghij' + '$')
>>> 36
>>>>>> sys.getsizeof('abcdefghij' + '€')
>>> 60
>>>>>> sys.getsizeof(('abcdefghij' + '€').encode('utf-8'))
>>> 30
>>>>>> sys.getsizeof('abcdefghij' + '\U00010000')
>>> 84
>>>>>> sys.getsizeof(('abcdefghij' + '\U00010000').encode('utf-8'))
>>> 31
>>>>>>
>>> Performance:
>>> "anti - utf-32"
>>>
>>> Buggyness:
>>> Better to not comment.
>>>
>>> Python is the single language, which is presenting the opposite of what
>>> Unicode.org offers on the side of memory *and* on the side of
>>> performance, utf-8 *and* utf-32 !
>>>
>>> Happy new year.
> He's right though. I would encourage anyone interested to check out
> http://utf8everywhere.org/
>
Niles, if you want to claim wxjmfauth is right, you'll have to present 
some actual evidence.  He's claimed for years that Python's Unicode 
support is buggy (as he does here), without ever demonstrating a bug.  
We've long ago tired of trying to reason with him.

The tradeoffs of memory use for algorithmic complexity are well 
understood, and have been endlessly discussed. There is not an 
"obviously right" answer to how to make those tradeoffs.

--Ned.



More information about the Python-list mailing list