By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,412 Members | 993 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,412 IT Pros & Developers. It's quick & easy.

It's Better CLEAR or NEW ?

P: n/a

I would like to hear your *opinion and advice* on best programming
practice under .NET.

Given that several time we cannot change:

MyCollection.Clear into the instantiation of a NEW MyCollection

because we make orphan some needed reference,

I notice also that several times I can "equivalently" decide whether a
collection
(or any other class) be cleared and reused or a NEW one should be
created.

This usually happens with collections having a class scope.

In such cases, where it is functionally "equivalent", and I can
choose, what is more advisable ?

It's better to clear a collection and reuse it. Or just instantiate a
brand new one leaving the old
one to the GC ?

I mean to the purpose of memory usage, speed, GC, etc.

-P

Sep 3 '07 #1
Share this Question
Share on Google+
34 Replies


P: n/a
In article <11**********************@r29g2000hsg.googlegroups .com>,
pa***********@libero.it says...
>
I would like to hear your *opinion and advice* on best programming
practice under .NET.

Given that several time we cannot change:

MyCollection.Clear into the instantiation of a NEW MyCollection

because we make orphan some needed reference,

I notice also that several times I can "equivalently" decide whether a
collection
(or any other class) be cleared and reused or a NEW one should be
created.

This usually happens with collections having a class scope.

In such cases, where it is functionally "equivalent", and I can
choose, what is more advisable ?

It's better to clear a collection and reuse it. Or just instantiate a
brand new one leaving the old
one to the GC ?

I mean to the purpose of memory usage, speed, GC, etc.
Just create a new one (assuming the elements of your collection don't
hold on to any unmanaged resources).

As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.

--
Patrick Steele (pa*****@mvps.org)
http://weblogs.asp.net/psteele
Sep 3 '07 #2

P: n/a
Patrick Steele wrote:
As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily for
the Pocket PC and Smartphone, so I really have to think about performance.
However, 'testing-in' performance and/or quality IMHO is not the right way.

Pamela, why don't you run some tests (just a few lines) and report back to
the group which was faster and by how much. Also, if this clear/new is in
an inner loop, it seems logical that clear would be better, but ignoring the
memory allocation and garbage collection piece of the puzzle, the speed diff
would be good info.

Thanks,

Hilton
Sep 3 '07 #3

P: n/a
Hilton <no****@nospam.comwrote:
Patrick Steele wrote:
As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.

I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily for
the Pocket PC and Smartphone, so I really have to think about performance.
However, 'testing-in' performance and/or quality IMHO is not the right way.
I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when
bottlenecks are often in unexpected places.

See

http://en.wikipedia.org/wiki/Optimiz...cience)#Quotes

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 3 '07 #4

P: n/a
On 3 Set, 19:13, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
Hilton <nos...@nospam.comwrote:
Patrick Steele wrote:
As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily for
the Pocket PC and Smartphone, so I really have to think about performance.
However, 'testing-in' performance and/or quality IMHO is not the right way.

I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when
Well we want both MACRO and micro-Optimize our code ! Do we ? :-))

Actually this is not a minor issue because this is a task that occurs
several times into
programs and if there is a raccomended way I would tend to go that
way.

In case you are implying that CLEAR would be " less readable ", I can
say that, for instance,
to be really safe, I would always recommend to anyon to use CLEAR and
not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.

You *really* must know what you are doing and watch carefully when you
indulge in a NEW
for a collection with class scope, and requires experience to stay out
of troubles.
Clearly I am talking of complex projects: in simple examples or
projects usually these issues do not appear....

I wish to hear the different opinions of yours on this matter, on the
basis of your
personal experience, especially on big programs ...
thanks :-)

-P
bottlenecks are often in unexpected places.


>
See

http://en.wikipedia.org/wiki/Optimiz...cience)#Quotes

--
Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Sep 3 '07 #5

P: n/a
On 3 Set, 19:49, pamela fluente <pamelaflue...@libero.itwrote:
On 3 Set, 19:13, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
Hilton <nos...@nospam.comwrote:
Patrick Steele wrote:
As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily for
the Pocket PC and Smartphone, so I really have to think about performance.
However, 'testing-in' performance and/or quality IMHO is not the right way.
I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when

Well we want both MACRO and micro-Optimize our code ! Do we ? :-))

Actually this is not a minor issue because this is a task that occurs
several times into
programs and if there is a raccomended way I would tend to go that
way.

In case you are implying that CLEAR would be " less readable ", I can
say that, for instance,
to be really safe, I would always recommend to anyon to use CLEAR and
not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.

You *really* must know what you are doing and watch carefully when you
indulge in a NEW
for a collection with class scope, and requires experience to stay out
of troubles.
Clearly I am talking of complex projects: in simple examples or
projects usually these issues do not appear....

I wish to hear the different opinions of yours on this matter, on the
basis of your
personal experience, especially on big programs ...

thanks :-)

-P
bottlenecks are often in unexpected places.
See
http://en.wikipedia.org/wiki/Optimiz...cience)#Quotes
--
Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too- Nascondi testo tra virgolette -

- Mostra testo tra virgolette -
Ok I have done a few quick tests.

As to speed only, It comes out that the CLEAR way is 2 times faster
(!).
hmm, that's seems almost surprising, actually.

-P
Sep 3 '07 #6

P: n/a
pamela fluente <pa***********@libero.itwrote:
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily for
the Pocket PC and Smartphone, so I really have to think about performance.
However, 'testing-in' performance and/or quality IMHO is not the right way.
I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when

Well we want both MACRO and micro-Optimize our code ! Do we ? :-))
It's worth optimising *some* things: making web service interfaces
bulky instead of chatty, looking at the complexity of algorithms in
big-O notation etc. That's a far cry from trying to make every bit of
code as fast as it can possibly be just *in case* it becomes a
bottleneck.
Actually this is not a minor issue because this is a task that occurs
several times into programs and if there is a raccomended way I would
tend to go that way.
How often is "several times"? There are a lot of things which may occur
"several times" during the lifecycle of an application, but still not
contribute significantly to performance.
In case you are implying that CLEAR would be " less readable ", I can
say that, for instance, to be really safe, I would always recommend
to anyon to use CLEAR and not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.
The problem is that it really *is* "generally speaking". In my view it
entirely depends on the context.
You *really* must know what you are doing and watch carefully when you
indulge in a NEW for a collection with class scope, and requires experience
to stay out of troubles.
Clearly I am talking of complex projects: in simple examples or
projects usually these issues do not appear....
In either case you need to know what you're doing. Sometimes the
collections will be visible elsewhere, sometimes they won't be.
Sometimes there's a performance impact, sometimes there isn't. It's one
of those decisions I'd look at on a case-by-case basis rather than
trying to come up with a hard and fast rule.

I wish to hear the different opinions of yours on this matter, on the
basis of your personal experience, especially on big programs ...
My personal experience is that the right answer varies by context.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 3 '07 #7

P: n/a
pamela fluente <pa***********@libero.itwrote:

<snip>
Ok I have done a few quick tests.

As to speed only, It comes out that the CLEAR way is 2 times faster
(!).

hmm, that's seems almost surprising, actually.
But have you tested whether it's *relevant* that clearing the
collection is faster? Is this even *slightly* significant in the
overall performance of your application? If not, use whichever code is
clearer.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 3 '07 #8

P: n/a
Hilton wrote:
Patrick Steele wrote:
>As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.

I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily for
the Pocket PC and Smartphone, so I really have to think about performance.
Everyone has to think about performance, regardless of platform.
Everyone should write code that performs well.

But for most code, all this really means is to not write inefficient
_algorithms_. Don't use an algorithm that is O(N^2), or even O(N log N)
for that matter, when an O(N) algorithm will do.

Differences in implementation of the same algorithm are not likely to
produce a performance difference that the user will notice in most
cases, while other aspects of the implementation such as overall code
maintainability and obviousness of the implementation details often do,
in the form of code that actually _works_ and doesn't have unanticipated
complications.

In addition, while one can test performance of a specific section of
code, there is not even any guarantee that such tests will translate
into a real-world application. There is more to the question of
performance than just what the basic CPU instruction timing can tell
you. For example, code that performs better in a specific scenario, but
which is larger than a similar, simpler version of the same algorithm
may in fact under-perform in other scenarios, whether due to interaction
with surrounding code or differences in the exact hardware
configuration, etc.

And of course, if you manage to squeeze a 50% improvement (an unusually
large optimization result, assuming a correct algorithm has been
designed in the first place) out of code that only consumes 1% or less
of the total execution cost, you haven't achieved anything the user will
ever care about.

So, even if you manage to prove one implementation performs better than
another in a specific situation, that isn't necessarily going to
translate into better performance for the end user.

Every software project has a finite amount of man-hours that can be
applied to it. You are doing your users a disservice if you spend some
of those man-hours optimizing code that has no need of optimization,
rather than doing things like adding features or ensuring that the code
is easily maintained, especially since those hours spent optimizing may
in fact have counter-productive results.

IMHO, the question of whether to use a new instance versus clearing an
existing one should relate more to what makes the code more readable
than which performs better. And in many cases, having an instance local
to a loop and which is initialized in each iteration of the loop is much
more readable and easily-maintained. (And in other cases, it may not be
in which case one would choose an alternate method).

As Patrick and Jon have both said, once you have a complete
implementation, then it makes sense to identify and address any
potential performance problems. At that point, you will know what areas
of the code are actually affecting the user experience, and you will be
able to measure changes in the implementation in a way that takes into
account the context of those changes.

Pete
Sep 3 '07 #9

P: n/a
pamela fluente wrote:
[...]
In case you are implying that CLEAR would be " less readable ", I can
say that, for instance,
to be really safe, I would always recommend to anyon to use CLEAR and
not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.
How so? How is creating a new instance and assigning to a variable
"very dangerous" as compared to clearing an existing instance already
referenced by the same variable?
You *really* must know what you are doing and watch carefully when you
indulge in a NEW
for a collection with class scope, and requires experience to stay out
of troubles.
What does the scope of the variable have to do with it? If you are
clearing the instance, surely that is just as dangerous as creating a
new one for the same variable.

Pete
Sep 3 '07 #10

P: n/a
pamela fluente wrote:
Ok I have done a few quick tests.

As to speed only, It comes out that the CLEAR way is 2 times faster
(!).
In what context? How did you measure the difference?

It is entirely possible that clearing a collection takes half the time
that creating a new instance does. But that difference is only relevant
if that's _all_ you are doing.

Both operations should be _very_ inexpensive, so if the code that uses
the collection is doing anything that is at all interesting, I would be
surprised if you found any useful difference in time cost using one
versus the other.

Pete
Sep 3 '07 #11

P: n/a
On 3 Set, 20:22, Peter Duniho <NpOeStPe...@NnOwSlPiAnMk.comwrote:
pamela fluente wrote:
[...]
In case you are implying that CLEAR would be " less readable ", I can
say that, for instance,
to be really safe, I would always recommend to anyon to use CLEAR and
not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.

How so? How is creating a new instance and assigning to a variable
"very dangerous" as compared to clearing an existing instance already
referenced by the same variable?
You *really* must know what you are doing and watch carefully when you
indulge in a NEW
for a collection with class scope, and requires experience to stay out
of troubles.

What does the scope of the variable have to do with it? If you are
clearing the instance, surely that is just as dangerous as creating a
new one for the same variable.

Pete
No, sorry. If you say that it means you are missing some important
points.

In complex applications it can occur that the Collection is used in
several other places
of the program. There also may be sublist of its items.

There is a fundamental difference between clearing and making a new
instance.

If you make a new instance, you may be left with a lot of orphans
around.
Trust me. Redefining as New a Collection used as a member of a class
is just the entrance of intricate debugging hell.

-P

Sep 3 '07 #12

P: n/a
pamela fluente wrote:
>What does the scope of the variable have to do with it? If you are
clearing the instance, surely that is just as dangerous as creating a
new one for the same variable.

No, sorry. If you say that it means you are missing some important
points.
No doubt. That's why I asked for clarification.
In complex applications it can occur that the Collection is used in
several other places
of the program. There also may be sublist of its items.

There is a fundamental difference between clearing and making a new
instance.
Yes, but not to the class where the instance exists. If the collection
is shared, yes...it would be up to the designer of the code to ensure
that the collection is used consistently. But that doesn't affect the
variable that's being changed itself. Hence my question.

You've explained better now what you mean. I would still assert that in
the scenario you describe, obviously performance is NOT the deciding
factor between one design and another. But at least now I have an idea
of what you're talking about.
Trust me. Redefining as New a Collection used as a member of a class
is just the entrance of intricate debugging hell.
Actually, it's not so much the using a new instance versus clearing
that's the issue here, as it is a design that allows for shared use of a
single instance without imposing some rules about how that single
instance is managed.

Pete
Sep 3 '07 #13

P: n/a
pamela fluente wrote:
I would like to hear your *opinion and advice* on best programming
practice under .NET.

Given that several time we cannot change:

MyCollection.Clear into the instantiation of a NEW MyCollection

because we make orphan some needed reference,

I notice also that several times I can "equivalently" decide whether a
collection
(or any other class) be cleared and reused or a NEW one should be
created.

This usually happens with collections having a class scope.

In such cases, where it is functionally "equivalent", and I can
choose, what is more advisable ?

It's better to clear a collection and reuse it. Or just instantiate a
brand new one leaving the old
one to the GC ?

I mean to the purpose of memory usage, speed, GC, etc.
That depends entirely on how you use the collections. Creating a new
collection will free up the allocated memory of the previous collection,
but reusing a collection might minimise reallocation of internal
buffers, as you hold on to the allocated memory. If you are short on
memory, you should definitely create a new collection.

The memory management in .NET is based on the fact that most objects are
short lived, so I would recommend that you just create a new collection
when needed, instead of trying to hold on to objects as long as possible.

Also, if you call Clear that will clear each reference in the
collection, while if you just remove the reference to the collection,
all references in the collection automatically gets unreachable without
any extra work at all.

--
Göran Andersson
_____
http://www.guffa.com
Sep 3 '07 #14

P: n/a


"pamela fluente" <pa***********@libero.itschreef in bericht
news:11**********************@19g2000hsx.googlegro ups.com...
On 3 Set, 19:49, pamela fluente <pamelaflue...@libero.itwrote:
>On 3 Set, 19:13, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
Hilton <nos...@nospam.comwrote:
Patrick Steele wrote:
As you develop your app, keep testing it for your desired
performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write
primarily for
the Pocket PC and Smartphone, so I really have to think about
performance.
However, 'testing-in' performance and/or quality IMHO is not the
right way.
I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when

Well we want both MACRO and micro-Optimize our code ! Do we ? :-))

Actually this is not a minor issue because this is a task that occurs
several times into
programs and if there is a raccomended way I would tend to go that
way.

In case you are implying that CLEAR would be " less readable ", I can
say that, for instance,
to be really safe, I would always recommend to anyon to use CLEAR and
not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.

You *really* must know what you are doing and watch carefully when you
indulge in a NEW
for a collection with class scope, and requires experience to stay out
of troubles.
Clearly I am talking of complex projects: in simple examples or
projects usually these issues do not appear....

I wish to hear the different opinions of yours on this matter, on the
basis of your
personal experience, especially on big programs ...

thanks :-)

-P
bottlenecks are often in unexpected places.
See
>http://en.wikipedia.org/wiki/Optimiz...cience)#Quotes
--
Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet
Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too- Nascondi testo tra
virgolette -

- Mostra testo tra virgolette -

Ok I have done a few quick tests.

As to speed only, It comes out that the CLEAR way is 2 times faster
(!).
hmm, that's seems almost surprising, actually.

-P

Hi Pamela

it isn`t 2 times faster although not on my system DELL Dimension 9200 ,
Dual core 6400 with 2 gb mem , IO stripe disk and 2 Gig 667 mem on windows
media center 2005
it is one time faster and one time slower , and sometimes the differences
are hughe ( for both ) run the test a few times on large collections and
and you wil notice this "strange" behavior


Sep 3 '07 #15

P: n/a
On 3 Set, 22:08, "Michel Posseth [MCP]" <msn...@posseth.comwrote:
"pamela fluente" <pamelaflue...@libero.itschreef in berichtnews:11**********************@19g2000hsx.go oglegroups.com...
On 3 Set, 19:49, pamela fluente <pamelaflue...@libero.itwrote:
On 3 Set, 19:13, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
Hilton <nos...@nospam.comwrote:
Patrick Steele wrote:
As you develop your app, keep testing it for your desired
performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write
primarily for
the Pocket PC and Smartphone, so I really have to think about
performance.
However, 'testing-in' performance and/or quality IMHO is not the
right way.
I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when
Well we want both MACRO and micro-Optimize our code ! Do we ? :-))
Actually this is not a minor issue because this is a task that occurs
several times into
programs and if there is a raccomended way I would tend to go that
way.
In case you are implying that CLEAR would be " less readable ", I can
say that, for instance,
to be really safe, I would always recommend to anyon to use CLEAR and
not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.
You *really* must know what you are doing and watch carefully when you
indulge in a NEW
for a collection with class scope, and requires experience to stay out
of troubles.
Clearly I am talking of complex projects: in simple examples or
projects usually these issues do not appear....
I wish to hear the different opinions of yours on this matter, on the
basis of your
personal experience, especially on big programs ...
thanks :-)
-P
bottlenecks are often in unexpected places.
See
http://en.wikipedia.org/wiki/Optimiz...cience)#Quotes
--
Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet
Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too- Nascondi testo tra
virgolette -
- Mostra testo tra virgolette -
Ok I have done a few quick tests.
As to speed only, It comes out that the CLEAR way is 2 times faster
(!).
hmm, that's seems almost surprising, actually.
-P

Hi Pamela

it isn`t 2 times faster although not on my system DELL Dimension 9200 ,
Dual core 6400 with 2 gb mem , IO stripe disk and 2 Gig 667 mem on windows
media center 2005
it is one time faster and one time slower , and sometimes the differences
are hughe ( for both ) run the test a few times on large collections and
and you wil notice this "strange" behavior


I made a simple experiment bu defining a collection of double
called "a" defined at class level and then with code simila to:
for (double i = 0; i <= 10000; i++) {
a.Add(i);
}
Stopwatch s = new Stopwatch();
s.Start();
for (int j = 0; j <= 100000; j++) {
a = new List<double>();
//a.Clear()
for (double i = 0; i <= 1000; i++) {
a.Add(i);
}
}
Interaction.MsgBox(s.Elapsed.TotalMilliseconds);
In various trials, the New took about 6 seconds and the Clear 3
seconds on my pc.

-P


Sep 3 '07 #16

P: n/a
pamela fluente <pa***********@libero.itwrote:
I made a simple experiment bu defining a collection of double
called "a" defined at class level and then with code simila to:
for (double i = 0; i <= 10000; i++) {
a.Add(i);
}
Stopwatch s = new Stopwatch();
s.Start();
for (int j = 0; j <= 100000; j++) {
a = new List<double>();
//a.Clear()
for (double i = 0; i <= 1000; i++) {
a.Add(i);
}
}
Interaction.MsgBox(s.Elapsed.TotalMilliseconds);
In various trials, the New took about 6 seconds and the Clear 3
seconds on my pc.
So what you mean is "clear a list and populate it with 1000 doubles" is
twice as fast as "create a new list and populate it with 1000 doubles".
There's a big difference there.

What happens if you change 1000 to 5? What happens if you change 1000
to 1000000? What happens if you use the List constructor which takes a
capacity?

More importantly: what does your real application do? And is the time
taken to clear/recreate the list actually significant?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 3 '07 #17

P: n/a
On 3 Set, 22:39, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
pamela fluente <pamelaflue...@libero.itwrote:
I made a simple experiment bu defining a collection of double
called "a" defined at class level and then with code simila to:
for (double i = 0; i <= 10000; i++) {
a.Add(i);
}
Stopwatch s = new Stopwatch();
s.Start();
for (int j = 0; j <= 100000; j++) {
a = new List<double>();
//a.Clear()
for (double i = 0; i <= 1000; i++) {
a.Add(i);
}
}
Interaction.MsgBox(s.Elapsed.TotalMilliseconds);
In various trials, the New took about 6 seconds and the Clear 3
seconds on my pc.

So what you mean is "clear a list and populate it with 1000 doubles" is
twice as fast as "create a new list and populate it with 1000 doubles".
There's a big difference there.

What happens if you change 1000 to 5? What happens if you change 1000
to 1000000? What happens if you use the List constructor which takes a
capacity?

More importantly: what does your real application do? And is the time
taken to clear/recreate the list actually significant?

--
Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Well, my point is probably :-) the following.

Although I wanted to hear the Your opinions, my current
believe is that one should *always* use CLEAR ,
because of conceptual reasons (no orphan references), even if much
slower.
(This is based on my experience on some millions lines of code,
but I may well change in the next million :-) )

Further, if it turned out that reusing is even faster than recreating,
then ... there would be no doubt about the best approach ...

Anyway I really am **interested** in sharing and hearing all the
opinions...

So go ahead ...

-P


Sep 3 '07 #18

P: n/a
pamela fluente <pa***********@libero.itwrote:
Well, my point is probably :-) the following.

Although I wanted to hear the Your opinions, my current
believe is that one should *always* use CLEAR ,
because of conceptual reasons (no orphan references), even if much
slower.
No, you shouldn't always use Clear. You should use whatever is most
appropriate to the situation. Sometimes you want to *logically* create
a new collection, sometimes you want to *logically* clear an existing
one.

It sounds like you've been stung by a situation where you created a new
collection when you should have cleared an existing one - changing to
*always* calling Clear, you're bound to be stung by the reverse
situation.

Rather than following one rule blindly, take account of different
situations and treat them on a case by case basis.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 3 '07 #19

P: n/a
"pamela fluente" <pa***********@libero.itwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
Well, my point is probably :-) the following.

Although I wanted to hear the Your opinions, my current
believe is that one should *always* use CLEAR ,
because of conceptual reasons (no orphan references), even if much
slower.
(This is based on my experience on some millions lines of code,
but I may well change in the next million :-) )

Further, if it turned out that reusing is even faster than recreating,
then ... there would be no doubt about the best approach ...

Anyway I really am **interested** in sharing and hearing all the
opinions...

You also haven't specified whether the lists (or have you?) will be
accessible from multiple threads of execution. Or whether the list is being
used as a backing store...

You referenced "orphans" in your above post. To me, this implies that there
is the possiblility that multiple objects are holding references to the same
list. Otherwise, orphaning (should) not come into the picture, becasuse
once you lose the reference to the list, you lose the reference to the
list's contents.

IIRC, the only speedup you'd see is if the list is rather large, because the
list will keep its maxsize and won't have to grow as you add new elements.
But I would think that time would be better spent focusing on other portions
of code for such minor speedup possibilities.

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

Sep 3 '07 #20

P: n/a
Pamela,

Did you ever try to avoid Class scope or even more try to avoid
Static/Shared members.

It will help you to make more maintanable programs in an OOP way.

Cor

"pamela fluente" <pa***********@libero.itschreef in bericht
news:11**********************@19g2000hsx.googlegro ups.com...
On 3 Set, 19:49, pamela fluente <pamelaflue...@libero.itwrote:
>On 3 Set, 19:13, Jon Skeet [C# MVP] <sk...@pobox.comwrote:
Hilton <nos...@nospam.comwrote:
Patrick Steele wrote:
As you develop your app, keep testing it for your desired
performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write
primarily for
the Pocket PC and Smartphone, so I really have to think about
performance.
However, 'testing-in' performance and/or quality IMHO is not the
right way.
I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when

Well we want both MACRO and micro-Optimize our code ! Do we ? :-))

Actually this is not a minor issue because this is a task that occurs
several times into
programs and if there is a raccomended way I would tend to go that
way.

In case you are implying that CLEAR would be " less readable ", I can
say that, for instance,
to be really safe, I would always recommend to anyon to use CLEAR and
not NEW because, from my
experience the second way can be *very* dangerous, generally speaking.

You *really* must know what you are doing and watch carefully when you
indulge in a NEW
for a collection with class scope, and requires experience to stay out
of troubles.
Clearly I am talking of complex projects: in simple examples or
projects usually these issues do not appear....

I wish to hear the different opinions of yours on this matter, on the
basis of your
personal experience, especially on big programs ...

thanks :-)

-P
bottlenecks are often in unexpected places.
See
>http://en.wikipedia.org/wiki/Optimiz...cience)#Quotes
--
Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet
Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too- Nascondi testo tra
virgolette -

- Mostra testo tra virgolette -

Ok I have done a few quick tests.

As to speed only, It comes out that the CLEAR way is 2 times faster
(!).
hmm, that's seems almost surprising, actually.

-P

Sep 4 '07 #21

P: n/a
Jon's right a pragmatic approach is what is required - I have been there on a
couple of occasions :)

Of course I could just prolong the discussion by disagreeing with the MVP's :)

Ollie Riches

"Jon Skeet [C# MVP]" wrote:
pamela fluente <pa***********@libero.itwrote:
Well, my point is probably :-) the following.

Although I wanted to hear the Your opinions, my current
believe is that one should *always* use CLEAR ,
because of conceptual reasons (no orphan references), even if much
slower.

No, you shouldn't always use Clear. You should use whatever is most
appropriate to the situation. Sometimes you want to *logically* create
a new collection, sometimes you want to *logically* clear an existing
one.

It sounds like you've been stung by a situation where you created a new
collection when you should have cleared an existing one - changing to
*always* calling Clear, you're bound to be stung by the reverse
situation.

Rather than following one rule blindly, take account of different
situations and treat them on a case by case basis.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 4 '07 #22

P: n/a
If a collection is not referenced any more, wouldn't its destructor/
finalize do the equivalent of clear anyhow so that the objects it
references are dereferenced.

Otherwise theres a potential for circular references that the GC can't
handle.

If I an correct then speed wise, doing a clear will be faster than
discarding + new.

Trying to time this stuff is always hard as a large part of the cost
could be in the GC, which could happen at any time.

Sep 4 '07 #23

P: n/a
On Sep 4, 3:02 pm, Tigger <t...@grunt.tvwrote:
If a collection is not referenced any more, wouldn't its destructor/
finalize do the equivalent of clear anyhow so that the objects it
references are dereferenced.
No, the finalizer doesn't need to do anything. I'd be very surprised
if ArrayList/List<Tetc *had* finalizers. The backing array won't be
treated as a "live" variable any more, so the previously referenced
objects can become eligible for GC (if there are no other references).

There's no real concept of "dereferencing" an object, because .NET
doesn't do reference counting.
Otherwise theres a potential for circular references that the GC can't
handle.
The GC can handle circular references just fine. It uses mark and
sweep, not reference counting.

Jon

Sep 4 '07 #24

P: n/a
The answer to this question is tied to the usage of Capacity. If you
store a thousand items and then make a new list a do the same thing
without setting capacity on either list, refilling will be twice as
fast as making a new list simply because the memory is already
allocated for a thousand items. In general clearing and then refilling
should save you an allocation unless your are adding more items than
the existing set contained.

Sep 4 '07 #25

P: n/a
"Patrick Steele" <pa*****@mvps.orgwrote in message
news:MP************************@msnews.microsoft.c om...
As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.
That's exactly why Pacman once run on a Comodore 64 with almost no CPU
and/or memory and that when it's developped today it takes a Core2Duo 2.8Ghz
to run it with 1Gb RAM and a 256Mb video card... Well, I push it up a bit,
but you know what I mean... Some programmers don't care about their code's
performance anymore. Yes it's a bit stupid to overoptimize, but it's
extremely important to use the right way first and not wait to see problems
appear before fixing them. If you can do it right at once, do it right. I
like to do things right once and never touch it again because I know it's
the best way possible. Well, it's my way of thinking, you're free to agree
or not...

"pamela fluente" <pa***********@libero.itwrote in message
news:11**********************@r29g2000hsg.googlegr oups.com...
In such cases, where it is functionally "equivalent", and I can
choose, what is more advisable ?

It's better to clear a collection and reuse it. Or just instantiate a
brand new one leaving the old
one to the GC ?
As for the question of Pamela, I've seen with experience that the clear is
often slower when you have a lot of items in the collection, but if you only
have a few, go for the clear... Actually, try to estimate the item count
you will have in the collection at any time and test it to use the most
effective way.

I hope it helps

ThunderMusic
Sep 4 '07 #26

P: n/a
Pamela,

Did you ever try to avoid Class scope or even more try to avoid
Static/Shared members.

It will help you to make more maintanable programs in an OOP way.

Cor
"pamela fluente" <pa***********@libero.itschreef in bericht
news:11**********************@r29g2000hsg.googlegr oups.com...
>
I would like to hear your *opinion and advice* on best programming
practice under .NET.

Given that several time we cannot change:

MyCollection.Clear into the instantiation of a NEW MyCollection

because we make orphan some needed reference,

I notice also that several times I can "equivalently" decide whether a
collection
(or any other class) be cleared and reused or a NEW one should be
created.

This usually happens with collections having a class scope.

In such cases, where it is functionally "equivalent", and I can
choose, what is more advisable ?

It's better to clear a collection and reuse it. Or just instantiate a
brand new one leaving the old
one to the GC ?

I mean to the purpose of memory usage, speed, GC, etc.

-P
Sep 4 '07 #27

P: n/a
For those who ask why I have send this twice, something strange was
happening, all my answers to the VB net newsgroup from today were gone, when
I opened this I saw later that this one had arived the C# newsgroup however
never the VB languages newsgroup.

Sorry for that,

Cor

Sep 4 '07 #28

P: n/a
On Sep 4, 9:04 am, not_a_commie <notacom...@gmail.comwrote:
The answer to this question is tied to the usage of Capacity. If you
store a thousand items and then make a new list a do the same thing
without setting capacity on either list, refilling will be twice as
fast as making a new list simply because the memory is already
allocated for a thousand items. In general clearing and then refilling
should save you an allocation unless your are adding more items than
the existing set contained.
On Sep 4, 9:04 am, not_a_commie <notacom...@gmail.comwrote:
The answer to this question is tied to the usage of Capacity. If you
store a thousand items and then make a new list a do the same thing
without setting capacity on either list, refilling will be twice as
fast as making a new list simply because the memory is already
allocated for a thousand items. In general clearing and then refilling
should save you an allocation unless your are adding more items than
the existing set contained.
It does depend on the context. However, I have found that clearing is
almost always preferable, if it is possible. However, it makes the
code longer, typically.

One way to think of it is the comparison of memory allocation/
deallocation to changing the size (assigning a member to 0) with other
values. I have found that systems under stress typically end up having
a lot of page faults when simple memory reuse is overlooked. However,
on systems with lots of free memory, or lots of user interaction,
letting the GC handle the orphaned memory is easier to write and read.

Blah blah = new Blah();
while (blehBleh)
{
blah.Clear();
blah.AddRange(blipityDoDah);
}

vs.

while (blehBleh)
{
Blah blah = new Blah(blipityDoDah);
}

I recently wrote an application that built Oracle Arrays dynamically
using List<Decimal>s. Since there were 26 lists that held multiples of
32, there was a lot of memory being moved around for the 26MB file.
Clearing actually was significantly faster, however that was due to
the nature of my application (the capacity was foreknown).

Blah,
Travis

Sep 5 '07 #29

P: n/a
Jon Skeet [C# MVP] wrote:
Hilton <no****@nospam.comwrote:
>Patrick Steele wrote:
As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.

I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily
for
the Pocket PC and Smartphone, so I really have to think about
performance.
However, 'testing-in' performance and/or quality IMHO is not the right
way.

I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when
bottlenecks are often in unexpected places.
Jon,

I never said we should micro-optimize all the code. However, I do think we
should continually address performance issues so that they don't jump up and
bite us at the end of the project, or worse, when the engineer working on
the code is no longer on the project and both the bugs and performance
issues are left to someone new on the project.

Hilton
Sep 5 '07 #30

P: n/a
Hilton <no****@nospam.comwrote:
Jon Skeet [C# MVP] wrote:
Hilton <no****@nospam.comwrote:
Patrick Steele wrote:
As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.

I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily
for
the Pocket PC and Smartphone, so I really have to think about
performance.
However, 'testing-in' performance and/or quality IMHO is not the right
way.
I'm with Patrick. There's little point in micro-optimising *all* the
code (and often making it less readable at the same point) when
bottlenecks are often in unexpected places.

I never said we should micro-optimize all the code. However, I do think we
should continually address performance issues so that they don't jump up and
bite us at the end of the project, or worse, when the engineer working on
the code is no longer on the project and both the bugs and performance
issues are left to someone new on the project.
You should certainly test performance at appropriate times rather than
at the end of the project - but the *testing* part of it is the
important one. Rather than write code assuming that the performance of
that section is important, you should test it so that you know, as far
as is reasonably possible.

Performance is very often achieved at the cost of readability, clarity
and simplicity. Those are not things I give up lightly - so I will only
do so where I can see a significant improvement.

Yes, your overall architecture and algorithms should be designed with
performance in mind, but at the "implementing a method" level it's
relatively unimportant if it can be fixed in one small area later on.

In particular, with the example in this thread, the decision about
whether to clear an existing list or create a new one should usually be
one of the most appropriate semantics, *not* one about performance.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 5 '07 #31

P: n/a
Peter Duniho wrote:
Hilton wrote:
>Patrick Steele wrote:
>>As you develop your app, keep testing it for your desired performance
benchmarks (speed, memory usage, etc...) Wait until you start to
actually see a problem to fix it.

I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily
for the Pocket PC and Smartphone, so I really have to think about
performance.

Everyone has to think about performance, regardless of platform. Everyone
should write code that performs well.

But for most code, all this really means is to not write inefficient
_algorithms_. Don't use an algorithm that is O(N^2), or even O(N log N)
for that matter, when an O(N) algorithm will do.
Yeah, true, but not. O(N^2) can sometimes be faster than O(N log N), so
sometimes the inefficient algorithm is faster. Anyway, I digress. Let me
give you an example, on the Pocket PC if you combine the Location and Size
calls into a single Bounds method call and change Controls.Add to
Parent=this, you get significant performance increase. These aren't
algorithmic changes, just very trivial code changes which provide huge
increases in performance.

Differences in implementation of the same algorithm are not likely to
produce a performance difference that the user will notice in most cases,
while other aspects of the implementation such as overall code
maintainability and obviousness of the implementation details often do, in
the form of code that actually _works_ and doesn't have unanticipated
complications.
See above, also there was my DateTimePicker experience. Adding a bunch of
these to a page required 45 seconds! After optimizing the code,
it now takes about 5 seconds. No algorithm change. It's just not true that
only changing algorithms gets you big changes.

[zap stuff we pretty much agree on; i.e. readability, don't optimize
something if is makes no difference, etc]
As Patrick and Jon have both said, once you have a complete
implementation, then it makes sense to identify and address any potential
performance problems. At that point, you will know what areas of the code
are actually affecting the user experience, and you will be able to
measure changes in the implementation in a way that takes into account the
context of those changes.
Well this arguement breaks down in many ways, here are a few:
1. This breaks the whole OOP concept; i.e. the object might work fine now
but when I come to reusing it, its performance sucks.
2. You might not be working on the project when the performance issues
become apparent.
3. You move the code to a different platform and it is painfully slow. You
could argue that this is a 'complete implementation' and you can now
optimize. But why not just do it right the first time.

Let me summarize here because I think I'm being a little misunderstood. I
do not suggest micro-optimizing everything. I strongly encourage
readability. I try comment every method and non-obvious lines of code. I
even line up the "=" on different lines (a topic for another thread). My
point is, is that we need to 'build-in' both performance and quality and not
leave it to suddenly rear its ugly head when the project is nearing
completion, deadlines aren't being met, and QA gets thrown a huge project to
test and then we have to start putzing around with the performance issues as
well as the bugs. Do it right the first time. It some method is run once
of startup and optimizing it changes it from 0.2 seconds to 0.1 seconds, of
course keep the most readable, least bug-susceptable version.

Hilton
Sep 5 '07 #32

P: n/a
Jon,

I think this is one of those disagreements that occur on the NGs where we
actually agree with each other perhaps 99% and we could argue it out over
days, but if we were sitting down over a cold Diet Coke, we could agree, but
done with it and move on in a few minutes.

Hilton
Sep 5 '07 #33

P: n/a
Hilton wrote:
>But for most code, all this really means is to not write inefficient
_algorithms_. Don't use an algorithm that is O(N^2), or even O(N log N)
for that matter, when an O(N) algorithm will do.

Yeah, true, but not. O(N^2) can sometimes be faster than O(N log N)
Differences in absolute times aside, I never said one should always use
O(N log N) over O(N^2).
, so
sometimes the inefficient algorithm is faster.
Yes, and often the efficient algorithm costs more to implement in
developer hours. But these are highly dependent on the specific
scenario. They cannot be resolved as a general solution; a general test
of performance isn't going to answer the question as to what the best
implementation for a specific situation is.

If anything, that simply reinforces my point: the first tier of
optimization has a lot more to do with overall use of programmer time
than it does with specific performance scenarios.
Anyway, I digress. Let me
give you an example, on the Pocket PC if you combine the Location and Size
calls into a single Bounds method call and change Controls.Add to
Parent=this, you get significant performance increase. These aren't
algorithmic changes, just very trivial code changes which provide huge
increases in performance.
But in situations where the user never notices those increases, it's not
worth your time to investigate the performance differences.

In the Location/Size example, it should be immediately apparent to the
programmer who is paying attention that setting two properties, each of
which might force an update of the instance, is going to cost more than
setting a single property that encapsulates both. You don't need to
profile the code to know that it's less expensive to batch up
layout-related assignments.

In the Add() method vs Parent property, the difference is less apparent,
but again in many cases the user will never know the difference. It's
my opinion that it's a problem that two apparently equivalent techniques
produce significantly different performance results (assuming they
do...you're not specific enough for me to comment on that). But it's
not practical to go around performance-testing all of the possible
mechanisms you might use the framework.

The framework itself _should_ minimize these differences. But even
inasmuch as it doesn't, it's not practical to write a performance test
every time you add some new use of a framework element.
See above, also there was my DateTimePicker experience. Adding a bunch of
these to a page required 45 seconds! After optimizing the code,
it now takes about 5 seconds. No algorithm change. It's just not true that
only changing algorithms gets you big changes.
I never said it was.

Furthermore, what led you to optimize the code? Did you actually
profile all of the possible implementations in a separate test harness
to determine precise performance differences between the various
techniques available to you, before even implementing the overall
behavior desired?

Or did you, as I think is more likely, write the code, identify a
performance issue, and investigate how to improve the issue?

I would almost never do the former. I've never argued against the latter.
[...]
>As Patrick and Jon have both said, once you have a complete
implementation, then it makes sense to identify and address any potential
performance problems. At that point, you will know what areas of the code
are actually affecting the user experience, and you will be able to
measure changes in the implementation in a way that takes into account the
context of those changes.

Well this arguement breaks down in many ways, here are a few:
1. This breaks the whole OOP concept; i.e. the object might work fine now
but when I come to reusing it, its performance sucks.
That does not "break the whole OOP concept". The OOP concept works just
fine, even if you don't address every possible performance scenario in
your initial implementation.

In fact, it is impossible to anticipate every use of an object, and one
must be prepared to resolve potential issues in the future through
fixing the existing implementation. Not only does this not "break the
whole OOP concept", the "whole OOP concept" is based around
encapsulation that allows for such repairs without affecting existing
users of an object.
2. You might not be working on the project when the performance issues
become apparent.
So? More the reason for the code to be maintainable first, performant
second.
3. You move the code to a different platform and it is painfully slow. You
could argue that this is a 'complete implementation' and you can now
optimize. But why not just do it right the first time.
Because you have no way to know what is "right". If there's a
performance difference that is platform dependent, there is every
possibility that different techniques are required for different
platforms. Optimizing the code on a given platform could very well
result in the least-optimal results on another.
Let me summarize here because I think I'm being a little misunderstood. I
do not suggest micro-optimizing everything. I strongly encourage
readability. I try comment every method and non-obvious lines of code. I
even line up the "=" on different lines (a topic for another thread). My
point is, is that we need to 'build-in' both performance and quality and not
leave it to suddenly rear its ugly head when the project is nearing
completion, deadlines aren't being met, and QA gets thrown a huge project to
test and then we have to start putzing around with the performance issues as
well as the bugs.
If you've "done it right the first time", performance issues are easily
addressed. High-level architecture, correct abstractions, maintainable
implementations all lead to flexible, easily-fixable code.

Obviously, there are certain aspects of performance that can be
addressed during the initial implementation. No one is suggesting
otherwise. We're talking about a specific class of performance
optimizations here though. Such as the difference between instantiating
a new collection versus clearing an existing one.

These kinds of "optimizations" cannot even necessarily be predicted
accurately outside of the real-world application, but beyond that they
often optimize areas of code that represent a tiny fraction of the total
cost of execution. It's inefficient and in many cases
counter-productive to worry about those kinds of optimizations until
they have been demonstrated to be actual problems in the final user
experience.

Pete
Sep 5 '07 #34

P: n/a
I can see you are discussing about optimization.

Actually I did not have in mind an optimization purpose.

Just to find the *best* way to do something I found often and I
was asking myself about..

That is, give a *class scope* Collection, it's CLEAR Vs NEW,

[my current preference, I confess, being towards clear, while I
consider
using New a "dissennate" practice potentially very very
dangerous ... :-) ]

-P
Sep 5 '07 #35

This discussion thread is closed

Replies have been disabled for this discussion.