Repository navigation
Read ASCII tables in chunks - #6458
Conversation
|
Hi there @taldcroft 👋 - thanks for the pull request! I'm just a friendly 🤖 that checks for issues related to the changelog and making sure that this pull request is milestoned and labeled correctly. This is mainly intended for the maintainers, so if you are not a maintainer you can ignore this, and a maintainer will let you know if any action is required on your part 😃. Everything looks good from my point of view! 👍 If there are any issues with this message, please report them here. |
|
WIP for memory optimization, but this is not so easy so punt for now. This is for future reference. |
|
@taldcroft - No need to address |
|
@bsipocz - Good point, WOOHOO for Py3 only! |
|
I can reproduce failures on my Windows but they are not exactly the same ones as Appveyor: There are also a couple of p.s. To run the tests, I rebased your branch here on top of master locally first before install. |
99d8352 to
92a7069
Compare
92a7069 to
2fe9a6f
Compare
2fe9a6f to
e11fbd3
Compare
|
@astrofrog @hamogu - this is ready for final review. The changes in |
|
One test still fails on Appveyor (which is an improvement over the two that I found a week ago). |
|
@pllim - argh, it was passing appveyor before the last commit. [EDIT] - well I thought it was, but maybe not? Sigh. |
|
At least I now have a functional Windows dev environment on my mac. |
|
It passed! There is a conflict though. |
|
|
||
| The ``chunk_size`` should generally be set to the largest value that is | ||
| reasonable given available system memory. There is overhead associated | ||
| with processing each chunk, so the fewer chunks the better. |
There was a problem hiding this comment.
I'll have time to look at the code next week, but a small comments on the docs:
- Say "If you file has a commented header and you do want to read it in chunks, you might want to uncomment the header using a text editing program and then use the read-in-chunks feature on the modified table".
There was a problem hiding this comment.
Done (but suggest using the no_header format + names arg instead).
|
Ah yes, the inplace resize for non-masked columns is no good in the case of a string that changes size. This should be an easy fix. |
Also tweak test to avoid int32/64 problem with Windows.
1833520 to
68c3aa1
Compare
Fixes #3334
This revives an old effort to be able to read large ASCII table files in smaller chunks. This implementation deals strictly with the fast (C/Cython-based) routines, since that would be the preferred way to read most large ASCII tables. As such it is a bit intricate. However, the good news is that all the formats supported by the fast reader, except for
commented_header, are supported for chunked reading.This implementation allows for reading a big file in chunks and then returning a single stacked table, OR getting the table chunks one at a time via a generator. The latter mode could be useful for scan-processing a large table where you don't actually need to keep everything in memory.
To do:
Change theLEAVE this for now. Doing this in a memory efficient way is actually a bit tricky becausetable.vstackof the chunked tables into something more efficient.vstackhas a lot of general purpose checking and machinery that isn't needed here.Columncannot be resized in place.For this PR punted on getting
commented_headerto work, but suggest a work-around in the docs. The way this was implemented in the fast reader is special-case from the rest that is a bit orthogonal to what I'm doing here so I am not immediately sure of a solution.