Skip to content
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

Enumerating over pypxlib.Table causes memory leak #29

Open
ghost opened this issue Dec 30, 2021 · 4 comments
Open

Enumerating over pypxlib.Table causes memory leak #29

ghost opened this issue Dec 30, 2021 · 4 comments

Comments

@ghost
Copy link

ghost commented Dec 30, 2021

I may be doing something incorrectly, but when using enumerate() over a Table object, memory balloons out of control and isn't released. I don't immediately have a fix, but I wanted to document it for others that might struggle with the same. Fantastic library, a million thanks for it.

@jmcarter17
Copy link

I have the same issue as well.
Not using enumerate, but using a generator (with a generator expression) to iterate over a table.

Is there a way to iterate over a table that does not cause a memory leak?
If so, that would help us tremendously.

Million thanks for this library, very useful.

@jmcarter17
Copy link

Here is an example of code that I use to iterate over the table (which causes memory leaks)

with Table(path_table) as table:
    data = (row.x, row.y, row.z for row in table if row.z > 0) 
    process(data)  # this saves the data to some postgresql database on the cloud

When running this snippet for multiple tables one after the other, the memory usage keeps increasing until we run out of memory and the program crashes.

I would be interested in learning of a work around that does not have the memory leak side effect.

@fievelmousekewitz
Copy link

I had the same issue and never found a way to stop the memory ballooning. It's been quite a while but if I remember right, this isn't actually an issue with pypxlib, but more an issue of how python does garbage collection with CTypes.

I DID get around the problem though. I switched to a 64-bit python interpreter and allowed my program to allocate more memory. GC does eventually catch up--my py script iterates over 16 million paradoxdb records and converts them to mssql in about an hour, without any memory related crashes.

Hope that helps, and I'm sorry you're in the same boat as me, dealing with a paradox database in 2022!

@jmcarter17
Copy link

jmcarter17 commented Sep 8, 2022

@fievelmousekewitz thanks.
Unfortunately, the code has to run on windows xp, with python2.7, with only 2 GB of ram (of which only 500MB are available). I might have to write a solution in pure C, maybe. Thanks for the info, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants