The Using() Statement

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Realistically, how efficient is the using() statement (not the directive)? If I do this

using (SolidBrush test = new SolidBrush(Color.Black))
(...


is it more efficient (performance and memory wise) than this

Solidbrush test = new SolidBrush(Color.Black)
test.Dispose()
test = null

Does it not matter? Is using() SLOWER? I'm really concerned about the difference because I have an app that can be drawing 50 times+ a second

Thanks

Yaron
 
The using statement is just a convenience so you don't have to write a try
finally block to ensure that you dispose your resources. Your other way does
not ensure that the object will be disposed should an exception arise (or if
you exit the routine before you hit your dispose call).

Yaron said:
Realistically, how efficient is the using() statement (not the directive)? If I do this:

using (SolidBrush test = new SolidBrush(Color.Black)) {
(...)
}

is it more efficient (performance and memory wise) than this:

Solidbrush test = new SolidBrush(Color.Black);
test.Dispose();
test = null;

Does it not matter? Is using() SLOWER? I'm really concerned about the
difference because I have an app that can be drawing 50 times+ a second.
 
if you have a long function then 'using' will be more efficient as the variable goes out of scope immediately
 
The same IL code is generated....

Andrew S (Infragistics) said:
The using statement is just a convenience so you don't have to write a try
finally block to ensure that you dispose your resources. Your other way does
not ensure that the object will be disposed should an exception arise (or if
you exit the routine before you hit your dispose call).

directive)?
If I do this:
difference because I have an app that can be drawing 50 times+ a second.
 
leelaram said:
if you have a long function then 'using' will be more efficient as
the variable goes out of scope immediately

No, that makes no difference - the JITter can tell when a variable is
no longer used, so by runtime it's effectively out of scope anyway.

using(...) is just a *safe* way of making sure you call Dispose, which
is simpler to type than its equivalent of:

Foo x = new Foo();
try
{
...
}
finally
{
x.Dispose();
}
 
Using is equivalent to:

SolidBrush test = new SolidBrush(Color.Black);
try {
// your stuff
}
finally { test.Dispose(); }

So, it will be marginally slower because VM will save the state of the
registers when the try block is entered (so that it can restore it if an
exception occurs).
On the other hand, the brush will always be disposed, even if an exception
occurs while inside the try block.

I think that the overhead introduced by "using" is not worth worrying about,
and that it is more important to guarantee that all GDI resources will be
properly released.

But if you think that this is really an issue in your case, you should
benchmark it. Just compare the two versions on a small example and see how
it goes. My guess is that you won't see any difference unless the try block
only contains a very simple and very very fast piece of drawing code.

Bruno.

Yaron said:
Realistically, how efficient is the using() statement (not the directive)? If I do this:

using (SolidBrush test = new SolidBrush(Color.Black)) {
(...)
}

is it more efficient (performance and memory wise) than this:

Solidbrush test = new SolidBrush(Color.Black);
test.Dispose();
test = null;

Does it not matter? Is using() SLOWER? I'm really concerned about the
difference because I have an app that can be drawing 50 times+ a second.
 
It's probably also worth mentioning that 'using' does a check against null
(if it will happily accept a null reference).

I would have thought the cost of creating/manipulating GDI objects would far
outweigh any advantage you could get by avoiding using using.

Of course, the only way to tell the difference (if any) would be to profile
with and without.

Personally I'd use it.
 
ONLY if the compiler can guarantee that no exception could be thrown within
the code block. Any code that calls a method or property or indexer could
throw...
 
Stu Smith said:
It's probably also worth mentioning that 'using' does a check against null
(if it will happily accept a null reference).

I would have thought the cost of creating/manipulating GDI objects would far
outweigh any advantage you could get by avoiding using using.

Of course, the only way to tell the difference (if any) would be to profile
with and without.

Personally I'd use it.

Hi Stu,

I'd use it too. I don't like this kind of "a priori" micro-optimization. I
always take the safe approach, and I only introduce these
micro-optimizations if the profiler tells me that their is really a
bottleneck.

Bruno.
 
Back
Top