<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 26 October 2014 12:54, Jeff Reback <span dir="ltr"><<a href="mailto:jeffreback@gmail.com" target="_blank">jeffreback@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>you should have a read here/<br><a href="http://wesmckinney.com/blog/?p=543" target="_blank">http://wesmckinney.com/blog/?p=543</a></div><div><br></div><div>going below the 2x memory usage on read in is non trivial and costly in terms of performance¬†</div></blockquote></div><br><br></div><div class="gmail_extra">If you know in advance the number of rows (because it is in the header, counted with wc -l, or any other prior information) you can preallocate the array and fill in the numbers as you read, with virtually no overhead.<br><br></div><div class="gmail_extra">If the number of rows is unknown, an alternative is to use a chunked data container like Bcolz [1] (former carray) instead of Python structures. It may be used as such, or copied back to a ndarray if we want the memory to be aligned. Including a bit of compression we can get the memory overhead to somewhere under 2x (depending on the dataset), at the cost of not so much CPU time, and this could be very useful for large data and slow filesystems. <br><br><br></div><div class="gmail_extra">/David.<br></div><div class="gmail_extra"><br>[1] <a href="http://bcolz.blosc.org/">http://bcolz.blosc.org/</a><br></div></div>