<p dir="ltr">On Oct 13, 2016 7:58 PM, "Claudio Freire" <<a href="mailto:klaussfreire@gmail.com">klaussfreire@gmail.com</a>> wrote:<br>
><br>
> 2016-10-13 17:36 GMT-03:00 Fernando Pelliccioni <<a href="mailto:fpelliccioni@gmail.com">fpelliccioni@gmail.com</a>>:<br>
> > 2016-10-12 19:51 GMT-03:00 Claudio Freire <<a href="mailto:klaussfreire@gmail.com">klaussfreire@gmail.com</a>>:<br>
> >><br>
> >> 2016-10-12 12:03 GMT-03:00 Javier Marcon <<a href="mailto:javiermarcon@gmail.com">javiermarcon@gmail.com</a>>:<br>
> >> >> Por otro lado, ¿cómo estás trabajando el CSV? Si lo leés y laburás<br>
> >> >> linea por linea no deberías tener problema de memoria... ¿Se puede ver<br>
> >> >> qué estás haciendo?<br>
> >> >><br>
> >> >> Slds.<br>
> >> >><br>
> >> > No puedo poner el código por el contrato de confidencialidad, pero lo<br>
> >> > que hace es leer el csv y arma varias listas, una lista que por cada<br>
> >> > fila del csv tiene una lista de los valores de la fila, una lista con<br>
> >> > los encabezados, una lista de keys de fila, etc.<br>
> >><br>
> >> Sin código va a ser difícil ayudarte, pero si te ponés a pensar, con<br>
> >> un input de 200MB tendrías que estar inflando muchísimo en memoria los<br>
> >> datos para estar teniendo problemas con el OOM - eso, o estás<br>
> >> laburando en una máquina demasiado chica.<br>
> >><br>
> >> Si estás laburando en python 2, recordá que los strings unicode pesan<br>
> >> 4x lo normal debido al encoding interno. Podés ahorrar mucha memoria<br>
> >> guardando byte strings en vez de unicode (ej: x.encode("utf8") al<br>
> >> ponerlo en la lista, y x.decode("utf8") al sacarlo de la lista). Es un<br>
> >> laburo, pero te puede mejorar la eficiencia notablemente.<br>
> >><br>
> >> En python 3, desde cierta versión (creo que 3.4), ésto es automático.<br>
> ><br>
> ><br>
> > ¿Por qué 4x?<br>
> > El encoding interno de los strings de CPython 2.x es el mismo que el de las<br>
> > versiones 3.0, 3.1 y 3.2.<br>
> > Recién en 3.3 lo cambian a un encoding dinámico<br>
> > (<a href="https://www.python.org/dev/peps/pep-0393/">https://www.python.org/dev/peps/pep-0393/</a>).<br>
> > Tanto en CPython 2.x como en CPython < 3.3 el encoding es UCS-2 o UCS-4<br>
> > (dependiendo de como se compile el intérprete).<br>
> ><br>
><br>
><br>
> Por eso que decís.<br>
><br>
> Casi todas las distros compilan con UCS-4 (UCS-2 es limitado), y UCS-4<br>
> pesa, en la mayoría de los inputs, 4x lo que pesa UTF8.</p>
<p dir="ltr">4x me pareció exagerado, ya que es 4x siempre y cuando estemos en los primeros 128 Codepoints. Si laburás con plain-english es así. Sino es 2x, 4/3x o 1x...</p>
<p dir="ltr">Mi Python 3.2 en Windows está compilado con UCS-2 ( 2x, 1x, 3/4x, 1/2x).</p>
<p dir="ltr">UCS-2 es limitado, es cierto, lo que no queda claro es que encoding usa CPython < 3.3, mirá: </p>
<p dir="ltr"><a href="https://mail.python.org/pipermail/python-dev/2008-July/080915.html">https://mail.python.org/pipermail/python-dev/2008-July/080915.html</a></p>
<p dir="ltr">Parece ser un UTF-16 a medias ya que no indexan por Codepoints ni graphemes, sino por Codeunits...</p>
<p dir="ltr">Al margen, el encoding dinámico que inventaron en 3.3 no me gustó para nada.</p>
<p dir="ltr">> _______________________________________________<br>
> pyar mailing list<a href="mailto:pyar@python.org.ar"> pyar@python.org.ar</a><br>
><a href="http://listas.python.org.ar/listinfo/pyar"> http://listas.python.org.ar/listinfo/pyar</a><br>
><br>
> PyAr - Python Argentina - Sitio web:<a href="http://www.python.org.ar/"> http://www.python.org.ar/</a><br>
><br>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina -<a href="http://www.usla.org.ar"> http://www.usla.org.ar</a><br>
</p>