Steven D'Aprano wrote:
A million items is not a lot of data. Depending on the size of each
object, that might be as little as 4 MB of data:
L = ['' for _ in xrange(10**6)]
sys.getsizeof(L)
4348732
Note that this sys.getsizeof() is only saying the size of the list, not
the size
* Steven D'Aprano:
On Wed, 20 Jan 2010 05:25:22 +0100, Alf P. Steinbach wrote:
* Steven D'Aprano:
On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
That's surprising. I wouldn't implement it that way at all. I'd use a
dynamically-expanding buffer as I suggested. That way you get a
Steven D'Aprano, 20.01.2010 07:12:
> On Wed, 20 Jan 2010 05:25:22 +0100, Alf P. Steinbach wrote:
>> That is a good argument for not doing the expanding buffer thing.
>> But such buffers may be generally present anyway, resulting from
>> optimization of "+".
>
> As near as I can determine, the CPyt
On Wed, 20 Jan 2010 05:25:22 +0100, Alf P. Steinbach wrote:
> * Steven D'Aprano:
>> On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
>>
>>> That's surprising. I wouldn't implement it that way at all. I'd use a
>>> dynamically-expanding buffer as I suggested. That way you get a
>>> sing
* Steven D'Aprano:
On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
That's surprising. I wouldn't implement it that way at all. I'd use a
dynamically-expanding buffer as I suggested. That way you get a single
pass and don't have to calculate anything before you begin. In the best
ca
On Tue, 19 Jan 2010 16:20:42 -0500, Gerald Britton wrote:
> That's surprising. I wouldn't implement it that way at all. I'd use a
> dynamically-expanding buffer as I suggested. That way you get a single
> pass and don't have to calculate anything before you begin. In the best
> case, you'd use
On Tue, 19 Jan 2010 11:26:43 -0500, Gerald Britton wrote:
> Interestingly, I scaled it up to a million list items with more or less
> the same results.
A million items is not a lot of data. Depending on the size of each
object, that might be as little as 4 MB of data:
>>> L = ['' for _ in xrang
Gerald Britton writes:
> That's surprising. I wouldn't implement it that way at all. I'd use a
> dynamically-expanding buffer as I suggested. That way you get a
> single pass and don't have to calculate anything before you begin. In
> the best case, you'd use half the memory (the result just f
[Wolfram Hinderer]
> Yes, list building from a generator expression *is* expensive. And
> join has to do it, because it has to iterate twice over the iterable
> passed in: once for calculating the memory needed for the joined
> string, and once more to actually do the join (this is implementation
>
That's surprising. I wouldn't implement it that way at all. I'd use a
dynamically-expanding buffer as I suggested. That way you get a
single pass and don't have to calculate anything before you begin. In
the best case, you'd use half the memory (the result just fits in the
buffer after its last
On 19 Jan., 21:06, Gerald Britton wrote:
> [snip]
>
>
>
> > Yes, list building from a generator expression *is* expensive. And
> > join has to do it, because it has to iterate twice over the iterable
> > passed in: once for calculating the memory needed for the joined
> > string, and once more to
Gerald Britton writes:
> [snip]
>
>>
>> Yes, list building from a generator expression *is* expensive. And
>> join has to do it, because it has to iterate twice over the iterable
>> passed in: once for calculating the memory needed for the joined
>> string, and once more to actually do the join (
[snip]
>
> Yes, list building from a generator expression *is* expensive. And
> join has to do it, because it has to iterate twice over the iterable
> passed in: once for calculating the memory needed for the joined
> string, and once more to actually do the join (this is implementation
> dependen
On 19 Jan., 16:30, Gerald Britton wrote:
> >>> Timer("' '.join([x for x in l])", 'l = map(str,range(10))').timeit()
>
> 2.9967339038848877
>
> >>> Timer("' '.join(x for x in l)", 'l = map(str,range(10))').timeit()
>
> 7.2045478820800781
[...]
> 2. Why should the "pure" list comprehension be slow
Interestingly, I scaled it up to a million list items with more or
less the same results. It's helpful to see that your results are
different. That leads me to suspect that mine are somehow related to
my own environment.
Still I think the key is the overhead in calling next() for each item
in th
On Tue, Jan 19, 2010 at 7:30 AM, Gerald Britton wrote:
[snip]
> mystring = '\n'.join( line for line in lines if depending on line> )
>
Note, this is not a list comprehension, but a generator comprehension.
A list comprehension is used to build, in one sweep, a list and return it.
A generator c
Thanks! Good explanation.
On Tue, Jan 19, 2010 at 10:57 AM, Alf P. Steinbach wrote:
> * Gerald Britton:
>>
>> Yesterday I stumbled across some old code in a project I was working
>> on. It does something like this:
>>
>> mystring = '\n'.join( [ line for line in lines if > depending on line> ] )
* Gerald Britton:
Yesterday I stumbled across some old code in a project I was working
on. It does something like this:
mystring = '\n'.join( [ line for line in lines if ] )
where "lines" is a simple list of strings. I realized that the code
had been written before you could put a list compr
Yesterday I stumbled across some old code in a project I was working
on. It does something like this:
mystring = '\n'.join( [ line for line in lines if ] )
where "lines" is a simple list of strings. I realized that the code
had been written before you could put a list comprehension as an
argum
19 matches
Mail list logo
