[CoMoDev] Re: Garbage collection
- From: "Darren Shaffer" <darren_shaffer@xxxxxxxxxxx>
- To: <comodev@xxxxxxxxxxxxx>
- Date: Thu, 18 Aug 2005 13:00:53 -0600
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:
