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 a
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 run because some syntax
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 buildbots, but I care about C
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
> constructs are very rarely
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
- test_t
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
- test_date
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
> tiny allocations, but
