[CoMoDev] Re: Garbage collection

  • From: "Andrei P." <andreip@xxxxxxxxxxxxxxxxx>
  • To: <comodev@xxxxxxxxxxxxx>
  • Date: Thu, 18 Aug 2005 12:01:31 -0600


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.


-----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.


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: