Skip to content

Performance degradation in 2.1.3 #605

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jeblair opened this issue Mar 8, 2017 · 3 comments · Fixed by #686
Closed

Performance degradation in 2.1.3 #605

jeblair opened this issue Mar 8, 2017 · 3 comments · Fixed by #686

Comments

@jeblair
Copy link
Contributor

jeblair commented Mar 8, 2017

Hi,

The recent commit f1a82e4 has caused a significant performance
degradation in the use of GitPython. As an example, one unit
test that we have which performs operations on about 42
repositories normally runs in 6.7 seconds, but with the two new
gc.collect() calls in f1a82e4 it now takes 24.2 seconds.

The gitdb.util.mman.collect() call does not seem to be expensive,
only gc.collect().

It's worth noting that most objects in python are freed by use of
reference counting, while gc.collect() invokes the garbage
collector, which is only needed to free objects with reference
cycles. Normally, the garbage collector runs periodically and
does not need to be explicitly invoked.

Since the garbage collector should only be effective on objects
which no longer have references from active frames, it's not
clear why these two calls to gc.collect() are required. It would
be nice to know if there are any other ways to address what they
are attempting to fix. If they truly are required in some
circumstances, it would be good to know what those are and if
there are cases where we do not need to invoke the expense. And
if they are not required, we should remove them.

Thanks!

openstack-gerrit pushed a commit to openstack-infra/zuul that referenced this issue Mar 8, 2017
It appears newer versions of GitPython have slowed considerably.
Cap GitPython until gitpython-developers/GitPython#605
is resolved.

Change-Id: Ie6c8722e8b607bb50e77fbad59e18363616f7e0d
Signed-off-by: Paul Belanger <[email protected]>
jamielennox pushed a commit to jamielennox/zuul that referenced this issue Mar 8, 2017
It appears newer versions of GitPython have slowed considerably.
Cap GitPython until gitpython-developers/GitPython#605
is resolved.

Change-Id: Ie6c8722e8b607bb50e77fbad59e18363616f7e0d
Signed-off-by: Paul Belanger <[email protected]>
jamielennox pushed a commit to jamielennox/zuul that referenced this issue Mar 8, 2017
It appears newer versions of GitPython have slowed considerably.
Cap GitPython until gitpython-developers/GitPython#605
is resolved.

Change-Id: Ie6c8722e8b607bb50e77fbad59e18363616f7e0d
Signed-off-by: Paul Belanger <[email protected]>
Signed-off-by: Jamie Lennox <[email protected]>
(cherry picked from commit 7b3f3be)
openstack-gerrit pushed a commit to openstack/openstack that referenced this issue Mar 9, 2017
Project: openstack-infra/zuul  7b3f3be326702ca20b49c88267e37c6f831114e1

Cap GitPython at 2.1.1 due to performance degradation

It appears newer versions of GitPython have slowed considerably.
Cap GitPython until gitpython-developers/GitPython#605
is resolved.

Change-Id: Ie6c8722e8b607bb50e77fbad59e18363616f7e0d
Signed-off-by: Paul Belanger <[email protected]>
openstack-gerrit pushed a commit to openstack-infra/zuul that referenced this issue Mar 9, 2017
It appears newer versions of GitPython have slowed considerably.
Cap GitPython until gitpython-developers/GitPython#605
is resolved.

Change-Id: Ie6c8722e8b607bb50e77fbad59e18363616f7e0d
Signed-off-by: Paul Belanger <[email protected]>
sf-project-io pushed a commit to redhat-cip/software-factory that referenced this issue Mar 13, 2017
See: gitpython-developers/GitPython#605

This change also fixes the nodepool health check where the last
image includes the jenkins repository which trigger an unexpected
update of jenkins when slave image is prepared

Change-Id: I60c919cdd987a9f3b8556b8e5f92f0f169cc392c
@ankostis
Copy link
Contributor

It's worth noting that most objects in python are freed by use of
reference counting,

Actually all objects were freed on ref-counting, till Python-3.5; since 3.5 that is not the case.
They are freed later, by a GC thread (I guess).
You rarely get to notice that in Linux - you can still delete files that are open.
But you bump into this every time you create a temp-file/folder on Windows, and then try to clean it up, because dead but non-GCed objects still prevent files from deleting.

Now, the "correct" way is to use WeakRef finalizers.
You can see all efforts into these issues by searching for tag.leaks.

Any improvement would be gladly accepted.

@Byron
Copy link
Member

Byron commented Apr 9, 2017

Indeed, this degradation was introduced in order to more promptly release file handles on windows. A possible fix could be to just enforce gc.collect() on windows, even though it appears like a hack on top of a hack.
@jeblair Would that help?
@ankostis Do you think doing so would be acceptable?

@ankostis
Copy link
Contributor

I expect all TCs to remain the same, it should be fine.

sf-project-io pushed a commit to softwarefactory-project/sf-config that referenced this issue Apr 26, 2017
See: gitpython-developers/GitPython#605

This change also fixes the nodepool health check where the last
image includes the jenkins repository which trigger an unexpected
update of jenkins when slave image is prepared

Change-Id: I60c919cdd987a9f3b8556b8e5f92f0f169cc392c
sf-project-io pushed a commit to softwarefactory-project/sf-ci that referenced this issue May 22, 2017
See: gitpython-developers/GitPython#605

This change also fixes the nodepool health check where the last
image includes the jenkins repository which trigger an unexpected
update of jenkins when slave image is prepared

Change-Id: I60c919cdd987a9f3b8556b8e5f92f0f169cc392c
@Byron Byron closed this as completed in #686 Nov 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

3 participants