For fun, let's multiply everything by 256:
- A "pool" becomes 1 MB.
- An "arena" becomes 64 MB.
As briefly suggested before, then for any given size class a pool
could pass out hundreds of times more objects before needing to fall
back on the slower code creating new pools or new arenas.
As an
On Jun 03, 2017, at 07:25 PM, Serhiy Storchaka wrote:
>But the latter example continuation lines are intended at the same level as
>the following block of code. I propose to make exception for that case and
>allow moving an open brace to the start of the next line.
>
> if (type->tp_dictoffset
Yet about braces. PEP 7 implicitly forbids breaking the line before an
opening brace. An opening brace should stay at the end the line of the
outer compound statement.
if (mro != NULL) {
...
}
else {
...
}
if (type->tp_dictoffset != 0 && base->tp_dictoffset
03.06.17 16:01, Antoine Pitrou пише:
On Sat, 3 Jun 2017 15:28:18 +0300
Serhiy Storchaka wrote:
test_tools (in particular the test for the unparse.py script),
test_tokenize, and test_lib2to3 read and proceed every Python file in
the stdlib. This is necessary in full test
On Sat, 3 Jun 2017 15:01:07 +0200
Antoine Pitrou wrote:
>
> > This is controlled by the cpy resource.
> > I suggested to disable it on the slowest buildbots (-uall,-cpu). In that
> > case tests are ran only for few random files.
>
> I don't really care about the
On Sat, 3 Jun 2017 15:28:18 +0300
Serhiy Storchaka wrote:
>
> test_tools (in particular the test for the unparse.py script),
> test_tokenize, and test_lib2to3 read and proceed every Python file in
> the stdlib. This is necessary in full test run because some syntax
>
03.06.17 13:31, Antoine Pitrou пише:
Is there a reason some of our tests are excruciatingly slow in `-uall`
mode? `test_multiprocessing_spawn` is understandable (after all, it
will spawn a new executable for each subprocess), but other tests leave
me baffled:
- test_tools: 7 min 41 sec
-
Hi,
Is there a reason some of our tests are excruciatingly slow in `-uall`
mode? `test_multiprocessing_spawn` is understandable (after all, it
will spawn a new executable for each subprocess), but other tests leave
me baffled:
- test_tools: 7 min 41 sec
- test_tokenize: 6 min 23 sec
-
On Fri, 2 Jun 2017 12:31:19 -0700
Larry Hastings wrote:
>
> Anyway, I'm not super excited by the prospect of using obmalloc for
> larger objects. There's an inverse relation between the size of
> allocation and the frequency of allocation. In Python there are lots of
>
On 3 June 2017 at 08:21, Nathaniel Smith wrote:
> On Fri, Jun 2, 2017 at 1:29 PM, Terry Reedy wrote:
>> On 6/2/2017 12:21 PM, Barry Warsaw wrote:
>>>
>>> On Jun 03, 2017, at 02:10 AM, Nick Coghlan wrote:
>>
>>
The benefit of making any backport a private
10 matches
Mail list logo