Which is More Efficient?

[Dustan]

I have a program that uses up a lot of CPU and want to make it is
efficient as possible with what I have to work with it. So which of the
following would be more efficient, knowing that l is a list and size is
a number?

l=l[:size]
del l[size:]

If it makes a difference, everything in the list is mutable.

 

[dan.gass]

Measure it and find out. Sounds like a little investment in your time
learning how to measure performance may pay dividends for you.

 

[Ben Finney]

I have a program that uses up a lot of CPU and want to make it is
efficient as possible with what I have to work with it.

Profile your program and find the precise parts that are the
slowest. Attempting to optimise before that is a waste of your time.

So which of the following would be more efficient, knowing that l is
a list and size is a number?

l=l[:size]
del l[size:]

Which one is more efficient in your program, when you profile its
performance?

<URL:http://docs.python.org/lib/profile.html>

 

[Fredrik Lundh]

I have a program that uses up a lot of CPU and want to make it is
efficient as possible with what I have to work with it. So which of the
following would be more efficient, knowing that l is a list and size is
a number?

l=l[:size]
del l[size:]

since you have the program, it shouldn't that hard to test the
two alternatives, should it ?

(in theory, del should be faster in most cases, since it avoids
creating another object. but the only way to tell for sure is
to try it out).

If it makes a difference, everything in the list is mutable.

the only difference between mutable and immutable objects in Python
is that mutable objects have methods that let you modify the object
contents, while immutable objects don't have such methods.

</F>

 

[John Machin]

1. Think about it. The first case will make a new list and copy "size"
*objects. When the assignment happens, the old list has its reference
count decremented. Not very memory-friendly. The second case merely
truncates the existing list in situ. Bit hard to imagine how the first
case could ever be faster than the second case. You might like to read
the source code. The file that you are looking for is listobject.c.
2. Measure it.
3. Unless you are deliberately parodying (e-mail address removed), don't use
"L".lower() as a variable name.
4. Try reading this list / newsgroup more often -- (a) this topic (or a
closely related one) was covered within the last week or so (b) you
might notice abuse like (3) above being hurled at others and avoid
copping your share.
HTH,
John

 

[Dustan]

1. Think about it. The first case will make a new list and copy "size"
*objects. When the assignment happens, the old list has its reference
count decremented. Not very memory-friendly. The second case merely
truncates the existing list in situ. Bit hard to imagine how the first
case could ever be faster than the second case. You might like to read
the source code. The file that you are looking for is listobject.c.

That's what I thought. I wasn't sure exactly what del actually does.

2. Measure it.

Tell me how and I will; I'm not nearly that much of a geek
unfortunately.

3. Unless you are deliberately parodying (e-mail address removed), don't use
"L".lower() as a variable name.

Don't understand what you mean by this, but I didn't actually use 'l'
as a variable name; that was just an example.

4. Try reading this list / newsgroup more often

I follow too many newsgroups as it is, when I've got plenty of other
stuff to do.

 

[Dustan]

I have a program that uses up a lot of CPU and want to make it is
efficient as possible with what I have to work with it. So which of the
following would be more efficient, knowing that l is a list and size is
a number?

l=l[:size]
del l[size:]

since you have the program, it shouldn't that hard to test the
two alternatives, should it ?

(in theory, del should be faster in most cases, since it avoids
creating another object. but the only way to tell for sure is
to try it out).

If it makes a difference, everything in the list is mutable.

the only difference between mutable and immutable objects in Python
is that mutable objects have methods that let you modify the object
contents, while immutable objects don't have such methods.

And it can be referenced by different variables. What I was saying was
that the contents weren't being copied over; it was only the list that
was being copied in the first statement.

 

[Fredrik Lundh]

Tell me how and I will; I'm not nearly that much of a geek
unfortunately.

do you have to be a geek to be able to measure how much time
something takes?

</F>

 

[Ben Finney]

Tell me how and I will; I'm not nearly that much of a geek
unfortunately.

You've already been told. Here it is again:

<URL:http://docs.python.org/lib/profile.html>

 

[Dustan]

do you have to be a geek to be able to measure how much time
something takes?

Obviously it takes a geek to know you have to time it, as opposed to
any other task you could be talking about.

 

[Fredrik Lundh]

Obviously it takes a geek to know you have to time it, as opposed to
any other task you could be talking about.

wasn't the original question "my program uses a lot of CPU, and I want
to make it more efficient" ? what does "a lot of CPU" and "more
efficient" mean to you, and how do you know that your program uses "a
lot of CPU" ?

</F>

 

[Dustan]

wasn't the original question "my program uses a lot of CPU, and I want
to make it more efficient" ? what does "a lot of CPU" and "more
efficient" mean to you, and how do you know that your program uses "a
lot of CPU" ?

The task manager says "CPU Usage: 100%" when the program is running,
and only when the program is running.

Efficiency is a measure of 2 things: CPU usage and time. If you measure
just time, you're not necessarily getting the efficiency.

 

[Dustan]

The task manager says "CPU Usage: 100%" when the program is running,
and only when the program is running.

Efficiency is a measure of 2 things: CPU usage and time. If you measure
just time, you're not necessarily getting the efficiency.

By the way, I've only been programming for a year or so (probably 18
months at the most). I'm sure that can't label me as a 'newbie', but at
least consider that before you criticize me like you did when I asked
about scientific notation.

 

[Max Erickson]

The task manager says "CPU Usage: 100%" when the program is
running, and only when the program is running.

Efficiency is a measure of 2 things: CPU usage and time. If you
measure just time, you're not necessarily getting the efficiency.

A lot of people, when they say 'uses a lot of CPU' are leaving off
'time'. I.e., CPU usage is pretty much talked about in terms of
cycles, which is roughly utilization*time. Profiling tools often
report both clock time and cpu time. Cpu time is a rough analog for
cycles, clock time is self explanatory.

max

 

[Fredrik Lundh]

The task manager says "CPU Usage: 100%" when the program is running,
and only when the program is running.

Efficiency is a measure of 2 things: CPU usage and time. If you measure
just time, you're not necessarily getting the efficiency.

are you for real?

</F>

 

[Dustan]

are you for real?

And what exactly is that supposed to mean?

 

[John Machin]

And what exactly is that supposed to mean?

The obscurity in that communication is probably caused by the instance
of the effbot with which you have been corresponding having been
invoked with mildmannered=True -- apparently this is not the default
value for that arg and the constraints so imposed can lead to lack of
precision in the output

HTH,
John