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]

"Dustan" <Du**********@gmail.com> writes:

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>

--
\ "Working out the social politics of who you can trust and why |
`\ is, quite literally, what a very large part of our brain has |
_o__) evolved to do." -- Douglas Adams |
Ben Finney

[Fredrik Lundh]

Dustan wrote:

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 b1**@aol.com, 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]

John Machin wrote:

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 b1**@aol.com, 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.
-- (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]

Fredrik Lundh wrote:

Dustan wrote:

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.

</F>

[Ben Finney]

"Dustan" <Du**********@gmail.com> writes:

John Machin wrote:

2. Measure it.

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>

--
\ "I don't know half of you half as well as I should like, and I |
`\ like less than half of you half as well as you deserve." -- |
_o__) Bilbo Baggins |
Ben Finney

[Fredrik Lundh]

Dustan wrote:

2. Measure it.

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>

[Dustan]

Fredrik Lundh wrote:

Dustan wrote:

2. Measure it.
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?

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

</F>

[Fredrik Lundh]

Dustan wrote:

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]

Fredrik Lundh wrote:

Dustan wrote:

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" ?

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.

</F>

[Dustan]

Dustan wrote:

Fredrik Lundh wrote:

Dustan wrote:

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" ?

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.

</F>

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]

"Dustan" <Du**********@gmail.com> wrote in
news:11**********************@u72g2000cwu.googlegr oups.com:

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]

Dustan wrote:

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]

Fredrik Lundh wrote:

Dustan wrote:

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?

And what exactly is that supposed to mean?

</F>

[John Machin]

Dustan wrote:

Fredrik Lundh wrote:

are you for real?

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