[CoMoDev] Re: Garbage collection

  • From: "Andrei P." <andreip@xxxxxxxxxxxxxxxxx>
  • To: <comodev@xxxxxxxxxxxxx>
  • Date: Thu, 18 Aug 2005 14:26:23 -0600

Darren,

 

I like your point about debugging a lot. I never went this way, but will go.

 

In the morning I wrote practically the same test as on the web site you
mentioned, but didn't have time to document the results.

Now I have them:

 

Performance is the same when concatenating 2 strings.

When it comes to 10 strings, SB is 4-5 times faster. Not mentioning GC
overhead.

 

So you gentlemen are absolutely right using SB instead of concatenating even
only 3 strings.

 

Thanks

 

Andrei

 

 

-----Original Message-----
From: comodev-bounce@xxxxxxxxxxxxx [mailto:comodev-bounce@xxxxxxxxxxxxx] On
Behalf Of Darren Shaffer
Sent: Thursday, August 18, 2005 1:01 PM
To: comodev@xxxxxxxxxxxxx
Subject: [CoMoDev] Re: Garbage collection

 

Andrei,

 

I read your original question as "what should I use if I'm receiving an

unknown number of strings

I have to concat together".   For this situation, as well as a very

efficient seek and

replace, StringBuilder is the way to go.  Here are metrics that indicate the

magic number

you are looking for is about 8 concats:

http://www.heikniemi.net/hc/archives/000124.html

 

Another, non-performance-oriented point:  which of the following two

statements is more

likely to fail the first time you code it and require debugging?

 

A.  string sql = "SELECT * FROM customers WHERE fname = '" +

      fname + "' AND '" lname = '" + lname + "'" +

      " AND title LIKE %" + title + "% " +

      "ORDER BY 1";

 

B.  StringBuilder sb = new StringBuilder();

      sb.Append("SELECT * FROM customers WHERE fname = '@fname' AND lname

= '@lname' AND title LIKE %@title% ORDER BY 1");

      sb.Replace("@fname", fname);

      sb.Replace("@lname", lname);

      sb.Replace("@title", title);

 

      

Microsoft best practices simply state that you should think of the

StringBuilder as an aggregator and

consider it the best choice when the number of runtime concatenations in

unknown.

 

Darren Shaffer

Principal Software Architect

Connected Innovation

Microsoft .NET Compact Framework MVP

darrens@xxxxxxxxxxxxxxxxxxxxxxx

(303) 886-1932

 

 

-----Original Message-----

From: comodev-bounce@xxxxxxxxxxxxx [mailto:comodev-bounce@xxxxxxxxxxxxx] On

Behalf Of Andrei P.

Sent: Thursday, August 18, 2005 12:02 PM

To: comodev@xxxxxxxxxxxxx

Subject: [CoMoDev] Re: Garbage collection

 

Dick,

 

You are absolutely right, that StringBuilder comes with a price.

I the days of good old COM we did a lot of performance experiments and come

to a result that for example it takes 30 microsecond to create a COM object

(on my Pentium those days) and we made our design decisions keeping in mind

those results. 

So I believe there is a performance penalty for the SB creation in oppose to

just allocation a piece of memory for a string.

Also if string variable is declared in a function, it is so called automatic

variable and goes to a stack and does not need GC at all. In this case the

only overhead comparing to say Int32 variable is a stack allocation

operation. Am I correct here about .NET? Java?

 

Strings are immutable in any language. And there is an overhead if one uses

them. For some reason Microsoft started to emphasize it in .NET (like Sun in

Java). Looks like in VB6 it was not so, but it was.

So my point is: there should be a rule like: use strings if you are

concatenating up to X of them, if more, use SB.

I am determined to find this X experimentally on the device, just need a

couple of free hours. I wish I had time to disassemble my future tests and

see what is actually happening behind the scenes.

 

I usually concatenate up to ten strings (example: socket request) hoping

that SB would imply a bigger overhead. My heaviest multiple-string operation

is parsing a socket response using string.Split(). My code is so much

shorter and more attractive there, then using Substring() and other string

operations. That's where I'm getting sometimes up to a hundred strings

array. I may reconsider my algorithms when I'll know X.

 

Andrei

 

 

-----Original Message-----

From: comodev-bounce@xxxxxxxxxxxxx [mailto:comodev-bounce@xxxxxxxxxxxxx] On

Behalf Of dick_grier Grier

Sent: Thursday, August 18, 2005 10:55 AM

To: comodev@xxxxxxxxxxxxx

Subject: [CoMoDev] Re: Garbage collection

 

Hi Andrei,

 

In general, I agree with Darren.  I use StringBuilder when concatenating,

with one exception (and this can be important, IMO).

 

The exception is when you must parse the resultant string (for whaterver

reason), immediately after concatenation.  If you have to parse, you must

convert the StringBuilder object to a String, and the result is that the use

 

of the StringBuilder actually can incure a performance penalty (especially

if the parsing process involve creation of multiple substrings).  However,

if the job simply involves appending new data, and perhaps occasional

cleanup, then StringBuilder is the way to go.

 

Dick

 

Richard Grier (Microsoft MVP - Visual Basic) Hard & Software

12962 West Louisiana Avenue

Lakewood, CO  80228

303-986-2179 (voice)

303-593-9315 (fax)

 

Author of Visual Basic Programmer's Guide to Serial Communications, 4th

Edition ISBN 1-890422-28-2 (391 pages) published July 2004. For faster

service, contact the publisher at http://www.mabry.com/vbpgser4.

 

 

 

 

 

 

Other related posts: