Eddie Elizondo added the comment:
It seems that we are back on track with perf being back to neutral!
I've created 4 new PRs. Each with an optimization applied on top of the
baseline introduction of instance immortalization.
The main PR 19474 currently stands at around 4%, after reb
Change by Eddie Elizondo :
--
pull_requests: +29621
pull_request: https://github.com/python/cpython/pull/31491
___
Python tracker
<https://bugs.python.org/issue40
Change by Eddie Elizondo :
--
pull_requests: +29620
pull_request: https://github.com/python/cpython/pull/31490
___
Python tracker
<https://bugs.python.org/issue40
Change by Eddie Elizondo :
--
pull_requests: +29619
pull_request: https://github.com/python/cpython/pull/31489
___
Python tracker
<https://bugs.python.org/issue40
Change by Eddie Elizondo :
--
pull_requests: +29618
pull_request: https://github.com/python/cpython/pull/31488
___
Python tracker
<https://bugs.python.org/issue40
Eddie Elizondo added the comment:
@eric.snow great to hear about this update! I'll start looking at some of the
techniques that we talked about to improve performance, I'm optimistic that
we'll be able to close down the gap to 2%.
--
___
Eddie Caraballo added the comment:
Issue seems to be with all power of 3 divisible by 5 (3**5, 3**10, etc).
Powers of 7 also seem to have the issue, where math.log(7**5, 7) = 5.01
--
___
Python tracker
<https://bugs.python.org/issue45
New submission from Eddie Caraballo :
math.log(243, 3) should result in 5.0, but instead results in 4....
Can be worked around via base conversion (math.log10(243) / math.log10(3))
--
components: Library (Lib)
messages: 403065
nosy: eddiemichaelc
priority: normal
severity: normal
Change by Eddie Peters :
--
keywords: +patch
pull_requests: +23522
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24752
___
Python tracker
<https://bugs.python.org/issu
New submission from Eddie Peters :
The unittest.mock library is very useful and very powerful, but it is not "very
easy to use." Docs are useful and important, or we wouldn't be here in a
documentation issue.
I have watched several of the most experienced Python programmers I
New submission from Eddie Parker :
Running the following yields an unexpected OSError: Invalid argument:
Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" f
Eddie Elizondo added the comment:
> which would potentially save the two word per object overhead
Btw, I misread. I thought `gc_bits` referred to the bits used by the GC in the
reference count. In any case, you can still use a bit in the reference co
Eddie Elizondo added the comment:
> I'm somewhat puzzled how a version that does no more work and has no jumps is
> slower.
Oh I think I know why there's some confusion. I've updated the PR from the
initial version (which is probably the one that you saw). The branchi
Eddie Elizondo added the comment:
Mark:
> You are asking the whole world to take a hit on both performance and memory
> use.
That's an explicit non-goal. That's why the code was guarded to add as an
optional compilation mode
This should be added by default if and only if t
Eddie Elizondo added the comment:
After the added optimizations and assuming that running this more rigorously
(i.e PGO + LTO + full cpu isolation + speed.python.org machine) also shows the
PR as perf neutral, what are people's thoughts so far?
Would this be enough to consider adding
Eddie Elizondo added the comment:
Neil:
> The fastest would be to create an immortal block as part of the BSS
> (uninitialized data).
That's an interesting idea, definitely worth exploring and we can probably get
some perf win out of it. And yes, using the frozen modules is d
Eddie Elizondo added the comment:
I was able to get an equal (maybe slightly better) performance by following the
advice from Steve and Neil and skipping reference counting of instances that we
know are immortal.
It seems that by getting performance parity, we should be able to ease most of
Eddie Elizondo added the comment:
> the CPU performance implications of adding a branch instruction to Py_INCREC
> and Py_DECREF were, unsurprisingly, quite high.
Yeah, makes sense. I guess it really depends on the specific profile of your
application.
For Instagram this was an overa
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +18829
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19474
___
Python tracker
<https://bugs.python.org/issu
New submission from Eddie Elizondo :
Copy on writes are a big problem in large Python application that rely on
multiple processes sharing the same memory.
With the implementation of `gc.freeze`, we've attenuated the problem by
removing the CoW coming from the GC Head. However, refe
Eddie Elizondo added the comment:
> I'm concerned by release blocker because 3.9.0a3 version is supposed to be
> released soon, and usually release blocker do block a release :-)
Ah! That makes sense!
In any case, feel free to ping me if you need help on my side to get this PR
Eddie Elizondo added the comment:
The PR that I sent out already fixes the issue. @vstinner, @pablogsal, please
take a look again https://github.com/python/cpython/pull/18039
That should close this issue, no need to work around the bug priority
Eddie Elizondo added the comment:
Hey all, I've got a fix for this bug and the CI is green:
https://github.com/python/cpython/pull/18039
TL;DR: The module state have to be cleared at a later time. I explain in detail
in the PR.
Also, I didn't add a new test since there was a tes
Change by Eddie Elizondo :
--
pull_requests: +17438
pull_request: https://github.com/python/cpython/pull/18039
___
Python tracker
<https://bugs.python.org/issue38
Eddie Elizondo added the comment:
PR with fix is out.
--
___
Python tracker
<https://bugs.python.org/issue35381>
___
___
Python-bugs-list mailing list
Unsub
Eddie Elizondo added the comment:
Victor, the PR with the fix is out. Easy catch after running it with my leak
detector!
--
___
Python tracker
<https://bugs.python.org/issue38
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +16856
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17373
___
Python tracker
<https://bugs.python.org/issu
Eddie Elizondo added the comment:
Woops! I'll get to it before the end of the weekend!
--
___
Python tracker
<https://bugs.python.org/issue35381>
___
___
Eddie Elizondo added the comment:
Woops! I'll get to it before the end of the weekend!
--
nosy: +eelizondo
___
Python tracker
<https://bugs.python.org/is
Eddie Elizondo added the comment:
Woops, just realized that you already documented this, thanks! Btw, Victor
already merged a fix for the windows compiler warning. This issue can be closed
now
--
___
Python tracker
<https://bugs.python.
Eddie Elizondo added the comment:
Hey Petr, I'll get to document this and fix the windows warning over the
weekend. I'll ping you on Github once it's ready
--
nosy: +eelizondo
___
Python tracker
<https://bugs.pyt
Eddie Elizondo added the comment:
The PR has been merged so the issue can be closed now
--
___
Python tracker
<https://bugs.python.org/issue38152>
___
___
Pytho
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +15738
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16127
___
Python tracker
<https://bugs.python.org/issu
Eddie Elizondo added the comment:
I have a fix for this coming up.
--
nosy: +eelizondo
___
Python tracker
<https://bugs.python.org/issue38152>
___
___
Python-bug
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +15730
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16115
___
Python tracker
<https://bugs.python.org/issu
Eddie Elizondo added the comment:
> Checking for refleak takes between 2 and 6 hours.
Ouch! Makes sense then.
We could potentially add a `pre-merge` job that only runs once the merge starts
to get executed. Anyways, that's a conversation for another time :-)
---
Thanks Stephane
Eddie Elizondo added the comment:
On it.
Also, I thought that the PR build bots already ran refleak tests by default? Do
you know why this it's not integrated to the PR flow?
--
nosy: +eelizondo
___
Python tracker
<https://bugs.py
Change by Eddie Elizondo :
--
pull_requests: +15700
pull_request: https://github.com/python/cpython/pull/16078
___
Python tracker
<https://bugs.python.org/issue34
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +15697
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16076
___
Python tracker
<https://bugs.python.org/issu
Change by Eddie Elizondo :
--
pull_requests: +15533
pull_request: https://github.com/python/cpython/pull/15892
___
Python tracker
<https://bugs.python.org/issue35
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +15040
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15323
___
Python tracker
<https://bugs.python.org/issu
New submission from Eddie Elizondo :
`subtype_dealloc` is not correctly handling the reference count of c heap type
subclasses. It has some builtin assumptions which can result in the type
getting its reference count decreased more that it needs to be, leading to its
destruction when it
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +12617
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36531>
___
___
Py
New submission from Eddie Elizondo :
If a user accidentally defined more than one Py_tp_members in the spec,
PyType_FromSpec will ignore all but the last use case. However, the number of
members count will cause the type to allocate more memory than needed. This
leads to weird behavior and
Eddie Elizondo added the comment:
> could we just remove the whole concept of heap allocated types?
I do have plans to start migrating more and more CPython modules to use heap
allocated types. For example I have posixmodule up in the queue (PR10854) and a
local change with all of
Eddie Elizondo added the comment:
Bump to get a review on the PR: https://github.com/python/cpython/pull/11661.
I believe all comments have now been addressed as well as adding a porting to
3.8 guide.
--
___
Python tracker
<ht
Eddie Elizondo added the comment:
> Please open a thread on python-dev
Done! https://mail.python.org/pipermail/python-dev/2019-February/156322.html
> Yes. You should add a new "Changes in the C API"
Done as well, I also included examples for the scenarios that will need
Eddie Elizondo added the comment:
Now, with that in mind - can you guys point me to the right thing to do now -
how can we move this forward? :)
* Should I write something up in python-dev/Discourse?
* Do I need to update the PY_VERSION_HEX?
* Do I need to write an entry in the Porting
Eddie Elizondo added the comment:
Thanks for the thorough feedback Stefan!
I would like to just add an extra thing to everything you already mentioned:
This change will NEVER cause a crash. The change that we are introducing is an
incref to a type object (no decrefs). Thus, there are two
Eddie Elizondo added the comment:
Hi Petr,
Please take a look at the Github PR. What do you think that's missing to move
this forward? I'd be more than happy to add more documentation/testing to it.
Let me know what you think
--
Change by Eddie Elizondo :
--
keywords: +patch, patch, patch
pull_requests: +11461, 11462, 11463
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Eddie Elizondo :
--
keywords: +patch, patch
pull_requests: +11461, 11462
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +11461
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35810>
___
___
Py
New submission from Eddie Elizondo :
Heap-allocated Types initializing instances through `PyObject_{,GC}_New{Var}`
will *NOT* not have their refcnt increased. This was totally fine under the
assumption that static types are immortal. However, heap-allocated types MUST
participate in
Eddie Elizondo added the comment:
I also fixed the title to properly reflect what this is trying to achieve.
--
___
Python tracker
<https://bugs.python.org/issue35
Change by Eddie Elizondo :
--
title: Extension modules using non-API functions -> Cleanup extension functions
using _PyObject_LookupSpecial
___
Python tracker
<https://bugs.python.org/issu
Eddie Elizondo added the comment:
@vstinner: Sorry for not being clear - The intention of this change is two-fold:
1) Simplify the implementation of these functions.
2) Reduce the surface area of the C-API.
Given that the same functionality can be achieved with public functions of the
C-API
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +10316
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35438>
___
___
Py
Eddie Elizondo added the comment:
Correction, this is not as trivial as just using `PyObject_GetAttrString`. Will
investigate the correct behavior.
--
___
Python tracker
<https://bugs.python.org/issue35
New submission from Eddie Elizondo :
Three extension modules: _testcapimodule.c, posixmodule.c, and mathmodule.c are
using `_PyObject_LookupSpecial` which is not API.
These should instead use `PyObject_GetAttrString`, `PyType_GetSlot`.
--
components: Library (Lib)
messages: 331364
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +10089
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35381>
___
___
Py
Change by Eddie Elizondo :
--
title: Heap-allocated Posixmodule types -> Heap-allocated posixmodule types
___
Python tracker
<https://bugs.python.org/issu
Change by Eddie Elizondo :
--
title: Heap-allocated Posixmodule -> Heap-allocated Posixmodule types
___
Python tracker
<https://bugs.python.org/issu
New submission from Eddie Elizondo :
After bpo34784, there are still two more cases of statically allocated types
(DirEntryType & ScandirIteratorType). These should also be heap allocated to
make posixmodule fully compatible with PEP384.
--
components: Library (Lib)
messages: 33
Change by Eddie Elizondo :
--
pull_requests: +10032
___
Python tracker
<https://bugs.python.org/issue16086>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eddie Elizondo :
--
pull_requests: +9062
___
Python tracker
<https://bugs.python.org/issue34784>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +8929
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34784>
___
___
Py
New submission from Eddie Elizondo :
PyStructSequence_NewType does not currently work. Read the full analysis here:
https://mail.python.org/pipermail/python-dev/2018-September/155069.html
This aims to fix the implementation of PyStructSequence_NewType.
--
components: Library (Lib
Eddie Elizondo added the comment:
@ronaldoussoren
* This change currently works for all CPython. If you are using this pattern
then you probably want to be using PyType_FromSpec rather than having a static
PyTypeObject as discussed in PEP384: https://www.python.org/dev/peps/pep-0384.
In
Eddie Elizondo added the comment:
@ronaldoussoren Please read the complete analysis from the mailing list:
https://mail.python.org/pipermail/python-dev/2018-August/154946.html. The
description here was just a rehash and I probably missed some context.
Particularly, when I said
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +8451
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34533>
___
___
Py
New submission from Eddie Elizondo :
This applies the heap type refactoring from PEP 384 to the _csv module.
--
components: Extension Modules
messages: 324268
nosy: eelizondo
priority: normal
severity: normal
status: open
title: Apply PEP384 to _csv module
type: enhancement
versions
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +8432
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34522>
___
___
Py
New submission from Eddie Elizondo :
>From the documentation, it says that PyType_Ready should be called on `ALL`
>type objects to finish their initialization
>(https://docs.python.org/3/c-api/type.html#c.PyType_Ready). This means that a
>PyTypeObject's ob_type should
Change by Eddie Elizondo :
--
keywords: +patch
pull_requests: +5852
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33058>
___
___
Py
Eddie Elizondo added the comment:
@serhiy.storchaka tracemalloc can't distinguish between the usage of gc allocs,
normal mallocs, and free list reuse.
--
___
Python tracker
<https://bugs.python.org/is
Eddie Elizondo added the comment:
Currently, Python has very few instrumentation when it comes to the types of
allocations that it's doing. For instance, we currently can't identify how many
times an object uses free lists vs actual mallocs.
Currently, there's a special bui
New submission from Eddie Elizondo :
[WIP]
--
title: [WIP] Enhance Python's Memory Instrumentation with COUNT_ALLCOS ->
Enhance Python's Memory Instrumentation with COUNT_ALLOCS
___
Python tracker
<https://bugs.pytho
Change by Eddie Elizondo :
--
nosy: elizondo93
priority: normal
severity: normal
status: open
title: Enhancing Python
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue33
Change by Eddie Elizondo :
--
title: [WIP] Enhancing Python's COUNT_ALLOCS -> [WIP] Enhance Python's Memory
Instrumentation with COUNT_ALLCOS
___
Python tracker
<https://bugs.pytho
Change by Eddie Elizondo :
--
title: Enhancing Python -> [WIP] Enhancing Python's COUNT_ALLOCS
___
Python tracker
<https://bugs.python.org/issue33058>
___
New submission from Eddie Elizondo :
The following build crashed:
mkdir debug && cd debug
../configure --with-pydebug
make EXTRA_CFLAGS="-DCOUNT_ALLOCS"
The bug was introduced here:
https://github.com/python/cpython/commit/25420fe290b98171e6d30edf9350292c21ef700e
Fix:
1)
Changes by Eddie James :
Added file: http://bugs.python.org/file44349/json-float-repr-2.7.patch
___
Python tracker
<http://bugs.python.org/issue27934>
___
___
Python-bug
Eddie James added the comment:
Python 2.7 also already behaves correctly for other dbus types:
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import
Eddie James added the comment:
Wait what about the json C code for 2.7? That's still using PyObject_Repr()
which will call tp_repr for dbus.Double... Any suggestions?
--
___
Python tracker
<http://bugs.python.org/is
Eddie James added the comment:
Thanks Mark, yes you installed the right package.
OK I didn't dig deep enough in the sub class. And yea, there shouldn't be any
difference between float.__repr__ and float.__str__. Obviously repr calls the
object's tp_repr method, while float.__r
Eddie James added the comment:
Understood on 2.7, I wasn't aware it would cause any issues.
Dbus.Double is not a subclass of float unfortunately. Problem is that all Dbus
types seem to have a custom tp_repr method that returns that strange formatting
I mentioned. So repr won't be t
Changes by Eddie James :
Added file: http://bugs.python.org/file44334/json-float-str-2.7.patch
___
Python tracker
<http://bugs.python.org/issue27934>
___
___
Python-bug
New submission from Eddie James:
JSON does not correctly encode dbus.Double types, even though all other dbus
types are handled fine. I end up with output like this (0.25 is the floating
point value): dbus.Double(0.25, variant_level=1)
Found that the encoding uses repr() for float objects but
New submission from Eddie Stanley:
Support for Berkeley DB up to 5.3 was introduced in Python 2.7.4 (see issue
#17477) however I'm having problems with the detection code in setup.py.
I'm working on RHEL4, I've got Berkeley DB 4.7.25 installed in /opt/db-4.7.25
When I try an
Changes by Eddie Slimak :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue5465>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Eddie Slimak :
I was mucking around attempting to get WConio working and so had an
installation for both python 2.5 and 2.6 at the same time. After I
uninstalled python 2.5 windows somehow stopped associating .py files
with python.
--
components: IDLE, Windows
Eddie added the comment:
Attached is a patch that solves (I hope) the initial problem, the one
from Francesco Ricciardi.
--
keywords: +patch
Added file: http://bugs.python.org/file12409/patch.diff
___
Python tracker
<http://bugs.python.
Eddie added the comment:
I read again what STINNER Victor and I think that he found another bug.
Because, when listing the filenames of that zip file, the names are not
displayed correctly. In fact
'x/h├⌐' == 'x/hé'.encode('utf-8').decode('cp437')
So,
Eddie added the comment:
The problem is not about reading the filenames, but reading the contents
of a file with filename that has non-ascii charaters.
___
Python tracker
<http://bugs.python.org/issue4
Eddie added the comment:
Sorry, my bad.
I did tried it but with the wrong version (2.5). And it worked perfectly.
So sorry again for my mistake.
Anyways, I've found the error.
The problem is caused by different encodings used when zipping.
In open, the method is comparing b't
Eddie added the comment:
The error you got is caused by giving the wrong parameters. You gave a
ZipInfo object instead of a filename.
If you execute data = testzip.read(t1.filename) yo will have no problems.
--
nosy: +Eddie
___
Python tracker
97 matches
Mail list logo
