String -> StringBuilder Optimization

  • Thread starter Thread starter Michael D. Ober
  • Start date Start date
M

Michael D. Ober

OK, I can't figure out a way to optimize the following VB 2005 code using
StringBuilders:

Public Const RecSize as Integer = 105
Private buffer As String

Public Sub New()
init
End Sub
Public Sub New(ByVal value As String)
buffer = LSet(value, 105)
End Sub

Public Sub init()
buffer = Space(105)
End Sub

Private Function fetch(ByVal start As Integer, ByVal chars As Integer) As
String
fetch = Mid(buffer, start, chars)
End Function
Private Sub putch(ByRef s As String, ByVal start As Integer, ByVal chars As
Integer)
Mid(buffer, start, chars) = LSet(s, chars)
End Sub

Public Property BUF() as String
Get
Return fetch(1, 105)
End Get
Set(ByVal value as string)
putch(value, 1, 105)
End Set
End Property

Public Property KEY0() as String
Get
Return fetch(1, 19)
End Get
Set(ByVal value as string)
putch(value, 1, 19)
End Set
End Property

' Additional fields are also defined in the same manner.

The public interface to this class must remain as strings, but I'd like to
optimize the implementation. Note that this is a sample from our interface
to a VMS BASIC environment and this code is actually being generated by a VB
6 program from the VMS Record Management Services (RMS) definition files.
Once a data record is in this object, I need to be able to change it, but
don't want to drive the GC nuts allocating/deallocating the internal buffer
string. For each class, the total length of buffer is fixed. I can't use a
simple record because RMS allows overlapping variants and the VB 6 program
has been coded to support that.

Mike Ober.
 
Michael D. Ober said:
OK, I can't figure out a way to optimize the following VB 2005 code using
StringBuilders:
Click to expand...

Can I ask a simple question? Are you experiencing performance problems with
this piece of code? Is it slow, or eating up all of your available memory
or something nasty like that?
 
So far, no performance issues, but it's used a lot - as in every single
field in our database runs through this type of code. Some of the tables
have over 100 fields (I didn't design it - I just have to live with it).

Mike.
 
Michael said:
OK, I can't figure out a way to optimize the following VB 2005 code using
StringBuilders:
Click to expand...

I don't think I would use a StringBuilder here. Maybe just a plain old
char array along with Buffer.BlockCopy. Strings could still be
returned when needed - just pass a char array to the string
constructor.
 
Hi Michael,

If you haven't experienced any issues then you might not want to concern yourself with modifying code that works, as I believe
Robinson was suggesting by asking questions related to the performance of your design, but I do understand if you only want to
perform some simple optimizations ahead of time.

That said, have you thought about using a StringDictionary instead of a StringBuilder or string buffer?

You might want to just parse the complete input string once, or parse each field on-demand and store the references to each of the
fields' values in case they are recalled at a later time. If you can design the class so that the parsing of each field is only
done once then a StringBuilder would be of no use, unless of course you need to rebuild the buffer for output with new values.

It might be cheaper to simply rebuild the buffer on-demand then it would be to perform string manipulation in each properties'
get/set accessor, but that of course depends on the number of property read/writes compared to the number of times your class will
need to rebuild the buffer for output and the actual tasks performed by each operation. I think, without those statistics, that
parsing in the get/set accessors each time will probably have an increased negative effect on your application's performance and the
GC more than if you were to cache the fields values in a StringDictionary and simply get/set them when required.

HTH
 
Michael,

I think using something else than as the code is now, will influence the
performance. It will in my idea go slower.

Cor
 
To Cor and all the other responders,

Thanks for all your imput. I'll leave it as is for now. I do have some
changes I'm thinking about to make the code itself easier to use, but the
basic structure will remain the same.

Mike Ober.
 
Michael D. Ober said:
To Cor and all the other responders,

Thanks for all your imput. I'll leave it as is for now. I do have some
changes I'm thinking about to make the code itself easier to use, but the
basic structure will remain the same.

Mike Ober.
Click to expand...

When I first came to .NET, I had trouble getting used to GC as I have a C++
background. Looking at all of the references created and the much larger
hit on memory really made me think I'd missed something important in my
implementation. It led me down the road of forcing the GC to collect
whenever I could. However, over time the stress hormone release from
watching the heap has decreased a great deal as my understanding of the CLR
has gone up. In your class above, I think you are already doing the best
you can without unintentionally obfuscating your code. Just don't look at
the heap so often - the GC will take care of all references no longer in
use, eventually.



Robin
 
Thanks - I was actually looking to see if anyone had ideas to reduce the
number of thrown away strings, which would in turn reduce the number of
allocations in the Gen(0) heap. Reducing these allocations would increase
the amount of time between runtime calls to the garbage collector, since
every allocation potentially involves a call to the garbage collector. From
my understanding of the system.string class, every single mid$() insert
statement will cause the internal string buffer to be thrown away and a new
one created (unlike in VB 6 where mid$() inserts replace part of the
existing string, but since the environment I'm working in is very heavily
string oriented, I couldn't see anyway to avoid this performance penalty,
which is why I asked.

As for explicitely calling the GC, I only do it when I need to get a picture
of how much memory is actually being used, and even then, I know it's only
an estimate. The GC in dotNet 2.0 appears to be one of the better ones on
the market, with only really long lived objects requiring true compaction
towards low memory. (On x86 processors, the heap almost always grows up
while the stack always grows down.) The GC of Gen(0) and Gen(1) memory is
nothing more than moving accessible gen(n) to the gen(n+1) heap and
adjusting the gen(n+1) heap free pointer, meaning that the GC doesn't have
to keep track of holes in memory until it gets to Gen(3). This makes Gen(0)
and Gen(1) compaction single pass, while keeping the full benefits of the
multi-pass Mark/Sweep/Compaction available to the runtime at the Gen(3) heap
level.

Mike Ober.
 
Michael D. Ober said:
Thanks - I was actually looking to see if anyone had ideas to reduce the
number of thrown away strings, which would in turn reduce the number of
allocations in the Gen(0) heap. Reducing these allocations would increase
the amount of time between runtime calls to the garbage collector, since
every allocation potentially involves a call to the garbage collector.
From my understanding of the system.string class, every single mid$()
insert statement will cause the internal string buffer to be thrown away
and a new one created (unlike in VB 6 where mid$() inserts replace part of
the existing string, but since the environment I'm working in is very
heavily string oriented, I couldn't see anyway to avoid this performance
penalty, which is why I asked.
Click to expand...

Yes, strings in .NET are immutable. I had a serious performance problem
with one of my methods that concatenated 10,000 or so "numbers" (string
numbers), with comma separators using normal string concatenation in my
project a while back. The stringbuilder gives an order of magnitude
performance increase in this case in terms of speed. I would however
optimize these special cases where a problem is identified but prefer
ordinary string manipulation otherwise.
 
Back
Top