It's Better CLEAR or NEW ?

[pamela fluente]

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

Given that several time we cannot change:

MyCollection.Cl ear into the instantiation of a NEW MyCollection

because we make orphan some needed reference,

I notice also that several times I can "equivalent ly" 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

[Patrick Steele]

In article <11************ **********@r29g 2000hsg.googleg roups.com>,
pa***********@l ibero.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.Cl ear into the instantiation of a NEW MyCollection

because we make orphan some needed reference,

I notice also that several times I can "equivalent ly" 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.o rg)
http://weblogs.asp.net/psteele

[Hilton]

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

[Jon Skeet [C# MVP]]

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.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[pamela fluente]

On 3 Set, 19:13, Jon Skeet [C# MVP] <[e-mail] mwrote:

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 - <[e-mail] m>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[pamela fluente]

On 3 Set, 19:49, pamela fluente <pamelaflue...@ libero.itwrote:

On 3 Set, 19:13, Jon Skeet [C# MVP] <[e-mail] mwrote:

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 - <[e-mail] m>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

[Jon Skeet [C# MVP]]

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.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

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

[Peter Duniho]

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

[Peter Duniho]

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