String performance optimization

[Guest]

A year or two ago, I read an article on Microsoft's MSDN or Patterns and
Practices site about application optimization when using strings. Some of
the recommendations were:

use string.Empty rather than "",
use string.Compare rather than myString == myOtherString,
etc., etc.

I have been searching for days now for that article or those performance
guidelines and can't find it. Does anyone know where that article, or any
similar Microsoft article may be found?

Thanks,

Dale

 

[Guest]

Refer the following articl
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp

 

[Guest]

That's a great article, but it doesn't address either of these specific
string performance issues.

I do appreciate your reply. If you, or anyone else, know of the article
that was devoted to string performance issues including the specific items I
listed, I would sure like to find it again.

Thanks again,

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

Refer the following article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp
--
Regards,
Amal [MCP, MCS]
http://geocities.com/techsharing

A year or two ago, I read an article on Microsoft's MSDN or Patterns and
Practices site about application optimization when using strings. Some of
the recommendations were:

use string.Empty rather than "",
use string.Compare rather than myString == myOtherString,
etc., etc.

I have been searching for days now for that article or those performance
guidelines and can't find it. Does anyone know where that article, or any
similar Microsoft article may be found?

Thanks,

Dale

 

[Guest]

Refer this
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt05.asp

and

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt13.asp

--
Regards,
Amal [MCP, MCS]
http://geocities.com/techsharing

That's a great article, but it doesn't address either of these specific
string performance issues.

I do appreciate your reply. If you, or anyone else, know of the article
that was devoted to string performance issues including the specific items I
listed, I would sure like to find it again.

Thanks again,

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

Refer the following article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp
--
Regards,
Amal [MCP, MCS]
http://geocities.com/techsharing

A year or two ago, I read an article on Microsoft's MSDN or Patterns and
Practices site about application optimization when using strings. Some of
the recommendations were:

use string.Empty rather than "",
use string.Compare rather than myString == myOtherString,
etc., etc.

I have been searching for days now for that article or those performance
guidelines and can't find it. Does anyone know where that article, or any
similar Microsoft article may be found?

Thanks,

Dale

 

[Guest]

Thank you again. More great articles and they're very helpful; I'd recommend
them to anyone.

The article I am looking for specifically addresses the issue of using
string.Empty instead of using "". The reason it gave, which makes sense to
me, is that string.Empty already exists while each time you use "" the
framework must allocate memory, create the necessary structure, and then
return the string.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

Refer this
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt05.asp

and

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt13.asp

--
Regards,
Amal [MCP, MCS]
http://geocities.com/techsharing

That's a great article, but it doesn't address either of these specific
string performance issues.

I do appreciate your reply. If you, or anyone else, know of the article
that was devoted to string performance issues including the specific items I
listed, I would sure like to find it again.

Thanks again,

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

Refer the following article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp
--
Regards,
Amal [MCP, MCS]
http://geocities.com/techsharing


:

A year or two ago, I read an article on Microsoft's MSDN or Patterns and
Practices site about application optimization when using strings. Some of
the recommendations were:

use string.Empty rather than "",
use string.Compare rather than myString == myOtherString,
etc., etc.

I have been searching for days now for that article or those performance
guidelines and can't find it. Does anyone know where that article, or any
similar Microsoft article may be found?

Thanks,

Dale

 

[Jon Skeet [C# MVP]]

Thank you again. More great articles and they're very helpful; I'd recommend
them to anyone.

The article I am looking for specifically addresses the issue of using
string.Empty instead of using "". The reason it gave, which makes sense to
me, is that string.Empty already exists while each time you use "" the
framework must allocate memory, create the necessary structure, and then
return the string.

That's completely wrong, as literals are interned.

In fact, String.Empty and "" end up as the same references. Personally
I prefer "" from a readability point of view, and *all* of these
performance "tips" should be taken with a heavy dose of common sense -
chances are that your app's performance bottleneck *isn't* going to be
affected by almost any of them. The one exception is string
concatenation in a loop, where a StringBuilder should be used.

 

[Chad Myers]

That's not true. The compiler (not even the JIT, if I recally correctly)
will optimize "".

At any rate, all string literals (strings with " and " around them) are
interned and so there is only ever ONE instance of them.

So even if "" weren't optimized by the compiler to be String.Empty, it would
be interned ONE time. You could have 15 million references
to "" in your code, but the compiler-or-JIT would convert them to a call to
retrieve the interned instance.

As far as String.Compare(), I'm not sure that it helps with simple x == y
comparions. Where it really helps is if you need to perform case-insensitive
and/or culture-insensitive comparisons.

-c

Thank you again. More great articles and they're very helpful; I'd
recommend
them to anyone.

The article I am looking for specifically addresses the issue of using
string.Empty instead of using "". The reason it gave, which makes sense
to
me, is that string.Empty already exists while each time you use "" the
framework must allocate memory, create the necessary structure, and then
return the string.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

Refer this
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt05.asp

and

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt13.asp

--
Regards,
Amal [MCP, MCS]
http://geocities.com/techsharing

That's a great article, but it doesn't address either of these specific
string performance issues.

I do appreciate your reply. If you, or anyone else, know of the
article
that was devoted to string performance issues including the specific
items I
listed, I would sure like to find it again.

Thanks again,

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA


:

Refer the following article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftips.asp
--
Regards,
Amal [MCP, MCS]
http://geocities.com/techsharing


:

A year or two ago, I read an article on Microsoft's MSDN or
Patterns and
Practices site about application optimization when using strings.
Some of
the recommendations were:

use string.Empty rather than "",
use string.Compare rather than myString == myOtherString,
etc., etc.

I have been searching for days now for that article or those
performance
guidelines and can't find it. Does anyone know where that article,
or any
similar Microsoft article may be found?

Thanks,

Dale

 

[Guest]

Thank you Jon and Chad. I appreciate the replies. That must be why the
specific article I remember can't be found anymore. It was probably removed
because it was in error.

Dale

--
Dale Preston
MCAD C#
MCSE, MCDBA