Inada Naoki added the comment:
@mpaolini I don't have enough time in these weeks. Would you try PR-15591?
I confirmed up to 4x speedup. But I'm afraid about there is performance
regression in simple cases.
--
___
Python tracker
<ht
Change by Inada Naoki :
--
pull_requests: +15267
pull_request: https://github.com/python/cpython/pull/15591
___
Python tracker
<https://bugs.python.org/issue37
Change by Inada Naoki :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Inada Naoki added the comment:
New changeset fae0ed5099de594a9204071d555cb8b76368cbf4 by Inada Naoki in branch
'master':
bpo-37328: remove deprecated HTMLParser.unescape (GH-14186)
https://github.com/python/cpython/commit/fae0ed5099de594a9204071d555cb8b76368cbf4
Inada Naoki added the comment:
thanks
--
nosy: +inada.naoki
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Inada Naoki added the comment:
When updating pip next time, please update setuptools too.
https://setuptools.readthedocs.io/en/latest/history.html#v41-1-0
> #1788: Changed compatibility fallback logic for html.unescape to avoid
> accessing HTMLParser.unescape when not nec
Inada Naoki added the comment:
New changeset 43d564c18c97421f73025ac3132a194975c76bd6 by Inada Naoki (Zackery
Spytz) in branch 'master':
bpo-37337: Fix a GCC 9 warning in Objects/descrobject.c (GH-14814)
https://github.com/python/cpython/commit/43d564c18c97421f73025ac3132a194975c76bd6
Inada Naoki added the comment:
It's just an implementation detail. Python implementation and C implementation
behave slightly different. But user program shouldn't rely on the detail.
Why do you think implementation details should be declared?
Who needs the information?
--
nosy
Change by Inada Naoki :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Inada Naoki added the comment:
New changeset 2a570af12ac5e4ac5575a68f8739b31c24d01367 by Inada Naoki in branch
'master':
bpo-37587: optimize json.loads (GH-15134)
https://github.com/python/cpython/commit/2a570af12ac5e4ac5575a68f8739b31c24d01367
Inada Naoki added the comment:
I'm conservative about adding public APIs.
But in this case, LIKELY/UNLIKELY macros are battle-tested in the world already.
So I think it's safe to make it public.
But I'll wait to merge for a week for other core dev's comments
Change by Inada Naoki :
--
keywords: +patch
pull_requests: +14890
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15156
___
Python tracker
<https://bugs.python.org/issu
Change by Inada Naoki :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue37781>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Inada Naoki :
MSVC 2015 supports "z" for size_t format.
I'm not sure about 2013.
AIX support it too. Now "z" is portable enough.
https://mail.python.org/archives/list/python-...@python.org/thread/CAXKWESUIWJNJFLLXXWTQDUWTN3F7KOU/#QVSBYYICHYC3
Change by Inada Naoki :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Inada Naoki added the comment:
New changeset 3e41f3cabb661824a1a197116f7f5ead64eb6ced by Inada Naoki (Sergey
Fedoseev) in branch 'master':
bpo-34488: optimize BytesIO.writelines() (GH-8904)
https://github.com/python/cpython/commit/3e41f3cabb661824a1a197116f7f5ead64eb6ced
Change by Inada Naoki :
--
components: +IO -Extension Modules
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue34488>
___
___
Inada Naoki added the comment:
And I confirmed performance improvement by my patch (GH-15134) on all of 4
compilers.
$ ./python -m pyperf timeit -s "import json; x = json.dumps({'k': '1' * 2 **
20})" "json.loads(x)"
old: 9211e2
new: 8a758f
opt2: 284e47
gcc (Ubuntu 8
Change by Inada Naoki :
--
pull_requests: +14873
pull_request: https://github.com/python/cpython/pull/15134
___
Python tracker
<https://bugs.python.org/issue37
Inada Naoki added the comment:
I tried without PGO and confirmed performance improved on GCC 7.2.0.
No change on other compiler versions.
$ ./python -m pyperf timeit -s "import json; x = json.dumps({'k': '1' * 2 **
20})" "json.loads(x)"
old: 9211e2
new: 8a758f
gcc (U
Change by Inada Naoki :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37761>
___
___
Change by Inada Naoki :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Inada Naoki added the comment:
New changeset e8ea34855c7635f8a84b430f17dc01a666f4c0ef by Inada Naoki (Miss
Islington (bot)) in branch '3.8':
bpo-37729: gc: write stats at once (GH-15050)
https://github.com/python/cpython/commit/e8ea34855c7635f8a84b430f17dc01a666f4c0ef
Inada Naoki added the comment:
While Py_SAFE_DOWNCAST is not documented, it doesn't start with underscore.
How many 3rd party code are broken by changing the name?
--
nosy: +inada.naoki
___
Python tracker
<https://bugs.python.org/issue19
Inada Naoki added the comment:
New changeset bf8162c8c45338470bbe487c8769bba20bde66c2 by Inada Naoki in branch
'master':
bpo-37729: gc: write stats at once (GH-15050)
https://github.com/python/cpython/commit/bf8162c8c45338470bbe487c8769bba20bde66c2
Change by Inada Naoki :
--
versions: -Python 3.7
___
Python tracker
<https://bugs.python.org/issue37729>
___
___
Python-bugs-list mailing list
Unsubscribe:
Inada Naoki added the comment:
I updated the PR to show "gc: collecting generation 0...\n" before counting
objects in each generations.
--
___
Python tracker
<https://bugs.python.o
Change by Inada Naoki :
--
keywords: +patch
pull_requests: +14801
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15050
___
Python tracker
<https://bugs.python.org/issu
New submission from Inada Naoki :
gc used several PySys_WriteStderr() calls to write stats.
This caused stats mixed up when stderr is shared by multiple
threads or processes.
Attached file (t.py) demonstrates it.
Sometimes stats from two processes are mixed up like this:
```
gc: collecting
Inada Naoki added the comment:
This issue is very compiler sensitive.
Please don't report performance without compiler version and PGO option.
Now I'm facing strange behavior. pyperf reports slower time (1ms) for PGO
builds, although disasm looks good.
But it's 2:30am already... Please wait
Inada Naoki added the comment:
I'm sorry, I was wrong. PGO did very nice job on all cases.
gcc allocates `c` to register in the hot loop.
--
___
Python tracker
<https://bugs.python.org/issue37
Inada Naoki added the comment:
I tested before, after, Steve's patch, and my patch with gcc 8.3.0 and PGO+LTO.
https://gist.github.com/methane/f6077bd1b0b04d40a9c790d9ed670a44#file-gcc-8-3-0-pgo-md
Surprisingly, there is no difference. Even my patch didn't help register
allocation when PGO
Inada Naoki added the comment:
Since scope of "c" is very wide, and there is even `` in the scope, compiler
stores the `c` to stack every time on:
c = PyUnicode_READ(kind, buf, next);
That is the bottleneck. `if (strict && ...)` is not the bottleneck.
My patch u
Inada Naoki added the comment:
Wait... there is no benchmark for the "minimum change".
I tested 4 compilers, and provide much better patch in
https://bugs.python.org/issue37587#msg348114
--
___
Python tracker
<https://bugs.python.o
Inada Naoki added the comment:
@steve.dower
Does the PGO have significant benefit for those modules?
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Inada Naoki :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37340>
___
Inada Naoki added the comment:
New changeset 3e54b575313c64f541e98216ed079fafed01ff5d by Inada Naoki in branch
'master':
bpo-37340: remove free_list for bound method objects (GH-14232)
https://github.com/python/cpython/commit/3e54b575313c64f541e98216ed079fafed01ff5d
Inada Naoki added the comment:
Latest benchmark:
```
$ pyperf compare_to master.json no-freelist.json -G --min-speed=2
Slower (2):
- unpickle_list: 4.19 us +- 0.02 us -> 4.28 us +- 0.03 us: 1.02x slower (+2%)
- pathlib: 23.2 ms +- 0.2 ms -> 23.7 ms +- 0.3 ms: 1.02x slower (+2%)
Fas
Inada Naoki added the comment:
New changeset 151b91dfd21a100ecb1eba9e293c0a8695bf3bf5 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-29548: deprecate PyEval_Call* functions (GH-14804)
https://github.com/python/cpython/commit/151b91dfd21a100ecb1eba9e293c0a8695bf3bf5
Inada Naoki added the comment:
OrderedDict is not recommended to preserve order any more.
Note that mention about `object_pairs_hook=OrderedDict` is removed
intentionally.
https://github.com/python/cpython/pull/5001
Please forget about OrderedDict unless you need additional feature
Inada Naoki added the comment:
2019年7月19日(金) 22:00 Phil Thompson :
>
> If I fail to protect against using a feature when it is no longer
> present then it's a bug in my code and it won't compile. Providing a
> deprecation warning gives me some notice that my code needs to
Inada Naoki added the comment:
> Which is why I protect the initialisation with #if PY_VERSION_HEX <
0x0309
It is your specific case. We can not assume people do it, or even you never
forget it. So this is not the "right thing" we can recommend to all users.
Once you
Inada Naoki added the comment:
> I am not "touching" tp_print. I am simply defining it as 0 to avoid the
> missing initialiser warning.
I meant it. `tp_print = 0` touches the deprecated `tp_print` field.
It is not forward compatible. Note that we need to re-add tp_print
Inada Naoki added the comment:
I think it's bad idea that suppressing deprecation warning to suppress the
warning for deprecated member.
It is highly recommended to "not" touching tp_print.
Why you want to suppress deprecation warning, not missing field initialisers?
You ca
Inada Naoki added the comment:
>./configure [...] --with-profile-task='-m test --pgo-extended'
I think this is abusing of `--with` options. `--with-*` is for external
software [1]. But `--with-lto` option abuses it already.
How about `./configure PROFILE_TASKS="-m test --pg
Inada Naoki added the comment:
New changeset d3952096537d9d2706e10af0c0596daeee6a58c9 by Inada Naoki (Zackery
Spytz) in branch 'master':
bpo-37547: Fix a compiler warning in winconsoleio.c (GH-14785)
https://github.com/python/cpython/commit/d3952096537d9d2706e10af0c0596daeee6a58c9
Inada Naoki added the comment:
https://docs.python.org/3/library/inspect.html#inspect.Parameter.replace
"""
Changed in version 3.4: In Python 3.3 Parameter objects were allowed to have
name set to None if their kind was set to POSITIONAL_ONLY. This is no lo
Change by Inada Naoki :
--
versions: -Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue37587>
___
___
Python-bugs-list mailin
Inada Naoki added the comment:
Some compilers produce inefficient code for PR-14752.
I wrote another patch which is friendly to more compilers.
$ perf record ./python -m pyperf timeit -s "import json; x = json.dumps({'k':
'1' * 2 ** 20})" "json.loads(x)"
# PR-14752
Inada Naoki added the comment:
> 1. remove the mov entirely. It is not needed inside the loop and it is only
> needed later, outside the loop to access the variable
How can we lazy "movDWORD PTR [rsp+0x44],eax"?
--
no
Inada Naoki added the comment:
New changeset fb26504d14a08fcd61bb92bb989b6d2b12188535 by Inada Naoki in branch
'master':
bpo-37543: optimize pymalloc (#14674)
https://github.com/python/cpython/commit/fb26504d14a08fcd61bb92bb989b6d2b12188535
Change by Inada Naoki :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Inada Naoki added the comment:
New changeset 1dbd084f1f68d7293718b663df675cfbd0c65712 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-29548: no longer use PyEval_Call* functions (GH-14683)
https://github.com/python/cpython/commit/1dbd084f1f68d7293718b663df675cfbd0c65712
Inada Naoki added the comment:
FYI, PyEval_CallFunction and PyEval_CallMethod doesn't respect Py_SSIZE_T_CLEAN.
So runtime warning is raised when they are used with "#" format.
--
___
Python tracker
<https://bugs.python.o
Inada Naoki added the comment:
New changeset 59ad110d7a7784d53d0b502eebce0346597a6bef by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37547: add _PyObject_CallMethodOneArg (GH-14685)
https://github.com/python/cpython/commit/59ad110d7a7784d53d0b502eebce0346597a6bef
Change by Inada Naoki :
--
keywords: +patch
pull_requests: +14489
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14674
___
Python tracker
<https://bugs.python.org/issu
New submission from Inada Naoki :
When PGO is not used, compilers don't know which part is hot.
So gcc failed to inline hot code in pymalloc_alloc and pymalloc_free
into _PyObject_Malloc and _PyObject_Free. For example, only this code is
inlined into _PyObject_Malloc.
if (nbytes == 0
Inada Naoki added the comment:
> Changing dict.update() calling convention may save a few nanoseconds on
> d1.update(d2) call, but it will make d1.update(**d2) way slower with a
> complexity of O(n): d2 must be converted to 2 lists (kwnames and args) and
> then a new dict shoul
Change by Inada Naoki :
--
keywords: +patch
pull_requests: +14457
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14646
___
Python tracker
<https://bugs.python.org/issu
Inada Naoki added the comment:
New changeset 762f93ff2efd6b7ef0177cad57939c0ab2002eac by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37337: Add _PyObject_CallMethodNoArgs() (GH-14267)
https://github.com/python/cpython/commit/762f93ff2efd6b7ef0177cad57939c0ab2002eac
Inada Naoki added the comment:
New changeset 6e43d07324ca799118e805751a10a7eff71d5a04 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37483: fix reference leak in _PyCodec_Lookup (GH-14600)
https://github.com/python/cpython/commit/6e43d07324ca799118e805751a10a7eff71d5a04
Change by Inada Naoki :
--
pull_requests: +14414
pull_request: https://github.com/python/cpython/pull/14599
___
Python tracker
<https://bugs.python.org/issue37
Inada Naoki added the comment:
OK, `d1.update(**d2)` is not useful in practice. Practical usages of
dict.update() are:
* d.update(d2)
* d.update([(k1,k2),...])
* d.update(k1=v1, k2=v2, ...)
* d.update(**d2, **d3, **d4) # little abuse, but possible.
In all of them, kwdict is not used
Inada Naoki added the comment:
- d2 = dict(**d1)
+ d2 = {"fizz": "buzz"}
+ d2.update(**d1)
--
___
Python tracker
<https://bugs.python.org/issue29312>
___
Inada Naoki added the comment:
> The unpacking is only a problem if you insist on using PyDict_Merge(). It
> would be perfectly possible to implement dict merging from a tuple+vector
> instead of from a dict. In that case, there shouldn't be a performance
> penalty.
Really?
Inada Naoki added the comment:
Can we call tp_call instead of vectorcall when kwargs is not empty?
https://github.com/python/cpython/blob/7f41c8e0dd237d1f3f0a1d2ba2f3ee4e4bd400a7/Objects/call.c#L209-L219
For example, dict_init may be faster than dict_vectorcall when `d2 =
dict(**d1
Inada Naoki added the comment:
How can we avoid unpacking dict in case of d1.update(**d2)?
--
___
Python tracker
<https://bugs.python.org/issue29312>
___
___
Inada Naoki added the comment:
New changeset 7f41c8e0dd237d1f3f0a1d2ba2f3ee4e4bd400a7 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37493: use _PyObject_CallNoArg in more places (GH-14575)
https://github.com/python/cpython/commit/7f41c8e0dd237d1f3f0a1d2ba2f3ee4e4bd400a7
Inada Naoki added the comment:
New changeset 196a530e00d88a138973bf9182e013937e293f97 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37483: add _PyObject_CallOneArg() function (#14558)
https://github.com/python/cpython/commit/196a530e00d88a138973bf9182e013937e293f97
Inada Naoki added the comment:
New changeset c7570d402e3ee8717615ffa020eb9e2215a77660 by Inada Naoki in branch
'3.8':
[3.8] bpo-37233: use _PY_FASTCALL_SMALL_STACK in method_vectorcall (GH-13974)
https://github.com/python/cpython/commit/c7570d402e3ee8717615ffa020eb9e2215a77660
Change by Inada Naoki :
--
pull_requests: +14391
pull_request: https://github.com/python/cpython/pull/14573
___
Python tracker
<https://bugs.python.org/issue37
Inada Naoki added the comment:
I don't want to add many functions to limited/public APIs.
Note that public APIs defined outside of cpython/ are considered mandatory for
all Python implementations supporting Python/C API.
When portability is more important than performance, there are many
Inada Naoki added the comment:
New changeset 53c214344038341ce86fcf7efa12dc33be9d5b45 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37233: optimize method_vectorcall in case of totalargs == 0 (GH-14550)
https://github.com/python/cpython/commit
Inada Naoki added the comment:
New changeset 469d1a70cecc918499c288fc0e5e3d79711bc5e5 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37484: use _PyObject_Vectorcall for __exit__ (GH-14557)
https://github.com/python/cpython/commit/469d1a70cecc918499c288fc0e5e3d79711bc5e5
Inada Naoki added the comment:
> It adds yet another special case underscore function that one cannot use in
> external projects. So I would not say that is simpler.
I don't get what you mean.
Do you care about *adding* API with underscore? If so, it doesn't make caller
code c
Inada Naoki added the comment:
This change doesn't make caller code complicated. It makes caller little
simpler.
Choosing performance sensitive code is much hard than replace all occurrences.
So I'm OK to change all callers except code owner opposed at once
Inada Naoki added the comment:
> Macros cannot be used in all C extensions. For the PEP 587, I was asked to
> replace macros with functions.
This is just an helper inline function / macro to ease calling
_PyObject_Vectorcall.
Extensions can port this helper inline function / macro t
Inada Naoki added the comment:
AFAIK, gcc, clang, and MSVC support it.
Another cons is, general pitfall of macro:
_PyObject_CALL_WITH_ARGS(func, PyDict_GetItem(d, key)); // PyDict_GetItem(d,
key) is called twice.
If two or more arguments are not common, I prefer _PyObject_CallOneArg
Inada Naoki added the comment:
What do you think about macro like this?
#define _PyObject_CALL_WITH_ARGS(func, ...) \
_PyObject_Vectorcall(func, (PyObject*[]){NULL, __VA_ARGS__} + 1, \
sizeof((PyObject*[]){__VA_ARGS__})/sizeof(PyObject*) |
PY_VECTORCALL_ARGUMENTS_OFFSET
Inada Naoki added the comment:
New changeset d4efd917ac24940063a1ce80073fe3570c5f07f8 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-36904: Optimize _PyStack_UnpackDict (GH-14517)
https://github.com/python/cpython/commit/d4efd917ac24940063a1ce80073fe3570c5f07f8
--
nosy
Inada Naoki added the comment:
I agree that this is a bug in many API docstrings, and PR 13933 is the right
approach to fix all bugs in the future.
But in case of dict.pop(), this is not only a bug, but a regression.
May I merge PR-13935 to fix the regression in 3.7b2
Inada Naoki added the comment:
> Oh! Fair enough, I had missed it. Does the note also involve `Py_BuildValue`?
> If so, the documentation of `Py_BuildValue` should probably be updated; if
> not, I think it would be clearer if the note mentioned that it only applies
>
Inada Naoki added the comment:
See note in https://docs.python.org/3.9/c-api/arg.html#strings-and-buffers
"""
Note: For all # variants of formats (s#, y#, etc.), the type of the length
argument (int or Py_ssize_t) is controlled by defining the macro
PY_SSIZE_T_CLEAN b
Inada Naoki added the comment:
New changeset b1263d5a60d3f7ab02dd28409fff59b3815a3f67 by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-37337: Add _PyObject_VectorcallMethod() (GH-14228)
https://github.com/python/cpython/commit/b1263d5a60d3f7ab02dd28409fff59b3815a3f67
Inada Naoki added the comment:
New changeset b4bee03087a3c70cb040e2ce569c828860ed8e87 by Inada Naoki (Hai Shi)
in branch 'master':
bpo-37432: Doc: Fix signature of PyObject_Del() (GH-14430)
https://github.com/python/cpython/commit/b4bee03087a3c70cb040e2ce569c828860ed8e87
--
nosy
Inada Naoki added the comment:
I think test_gdb is useful for 3.8 branch because some PEP 590 relating changes
will be backported to it.
But I don't know how test_gdb is useful for older branches.
--
___
Python tracker
<https://bugs.python.
Inada Naoki added the comment:
New changeset 21cfae107e410bf4b0ab3c142ca4449bc33290f5 by Inada Naoki in branch
'master':
bpo-30345: travis: use -Og with --with-pydebug (GH-14423)
https://github.com/python/cpython/commit/21cfae107e410bf4b0ab3c142ca4449bc33290f5
Change by Inada Naoki :
--
pull_requests: +14239
pull_request: https://github.com/python/cpython/pull/14423
___
Python tracker
<https://bugs.python.org/issue30
Inada Naoki added the comment:
New changeset 667eaffb4e5d03bf8129773f79649c3befaa5b1a by Inada Naoki (Jeroen
Demeyer) in branch 'master':
bpo-33926: enable GDB tests on Travis CI (GH-14395)
https://github.com/python/cpython/commit/667eaffb4e5d03bf8129773f79649c3befaa5b1a
--
nosy
Inada Naoki added the comment:
This optimization is only for short strings. There is no significant
difference for long and non-ASCII strings.
```
# 1000 ASCII
$ ./python -m pyperf timeit --compare-to=./python-master -s 'b=b"f"*1000' --
'b.decode()'
python-master: ...
Inada Naoki added the comment:
You can use `where pip` to find which pip is used.
And you can check `PATH` environment variable and remove unused PATHs.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pytho
Change by Inada Naoki :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Inada Naoki added the comment:
New changeset 770847a7db33b3d4c451b42372b6942687aa6121 by Inada Naoki in branch
'master':
bpo-37348: optimize decoding ASCII string (GH-14283)
https://github.com/python/cpython/commit/770847a7db33b3d4c451b42372b6942687aa6121
Inada Naoki added the comment:
There may be a broken pip.exe in your computer.
Try `python -VV` to check what python are you using.
After that, try `python -m pip`, instead of `pip`.
--
nosy: +inada.naoki
___
Python tracker
<ht
Inada Naoki added the comment:
PR 14291 seems simpler than PR 14283. But PR 14283 is faster because
_PyUnicodeWriter is a learge struct.
master: 3.7sec
PR 14283: 2.9sec
PR 14291: 3.45sec
compiler: gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
without LTO, without PGO
Change by Inada Naoki :
--
pull_requests: +14114
pull_request: https://github.com/python/cpython/pull/14291
___
Python tracker
<https://bugs.python.org/issue37
Inada Naoki added the comment:
Another micro benchmark:
```
$ ./python-master -m pyperf timeit -o m1.json 'b=b"foobar"' -- 'b.decode()'
.
Mean +- std dev: 93.1 ns +- 2.4 ns
$ ./python -m pyperf timeit -o m2.json 'b=b"foobar"' -- 'b.decode()'
..
Inada Naoki added the comment:
> I don't understand how _PyUnicodeWriter could be slow. It does not
> overallocate by default. It's just wrapper to implement efficient memory
> management.
I misunderstood _PyUnicodeWriter. I thought it caused one more allocation, but
i
Change by Inada Naoki :
--
pull_requests: +14105
pull_request: https://github.com/python/cpython/pull/14283
___
Python tracker
<https://bugs.python.org/issue37
Inada Naoki added the comment:
Oh, wait. Why we used _PyUnicodeWriter here?
Decoding UTF-8 must not require it. 2-pass is enough.
--
___
Python tracker
<https://bugs.python.org/issue37
901 - 1000 of 3038 matches
Mail list logo
