|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
String -> StringBuilder OptimizationStringBuilders: 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" <ober***@.alum.mit.edu.nospam> wrote in message Can I ask a simple question? Are you experiencing performance problems with news:uwE14894GHA.4196@TK2MSFTNGP03.phx.gbl... > OK, I can't figure out a way to optimize the following VB 2005 code using > StringBuilders: 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. Show quote "Robinson" <itoldyounottospamme@nowmyinboxisfull.com> wrote in message news:efjiaj$i0b$1$8302bc10@news.demon.co.uk... > > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message > news:uwE14894GHA.4196@TK2MSFTNGP03.phx.gbl... >> OK, I can't figure out a way to optimize the following VB 2005 code using >> StringBuilders: > > 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? > Michael D. Ober wrote:
> OK, I can't figure out a way to optimize the following VB 2005 code using I don't think I would use a StringBuilder here. Maybe just a plain old> StringBuilders: > char array along with Buffer.BlockCopy. Strings could still be returned when needed - just pass a char array to the string constructor. -- Tom Shelton 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 -- Show quoteDave Sexton "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message news:uwE14894GHA.4196@TK2MSFTNGP03.phx.gbl... > 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,
I think using something else than as the code is now, will influence the performance. It will in my idea go slower. Cor Show quote "Michael D. Ober" <ober***@.alum.mit.edu.nospam> schreef in bericht news:uwE14894GHA.4196@TK2MSFTNGP03.phx.gbl... > 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. > > 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. Show quote "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message news:euYNf1E5GHA.4196@TK2MSFTNGP03.phx.gbl... > Michael, > > I think using something else than as the code is now, will influence the > performance. It will in my idea go slower. > > Cor > > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> schreef in bericht > news:uwE14894GHA.4196@TK2MSFTNGP03.phx.gbl... > > 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" <ober***@.alum.mit.edu.nospam> wrote in message When I first came to .NET, I had trouble getting used to GC as I have a C++ news:_eyTg.999$Lv3.860@newsread1.news.pas.earthlink.net... > 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. > 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. Show quote "Robinson" <itoldyounottospamme@nowmyinboxisfull.com> wrote in message news:efqo6v$rnb$1$8300dec7@news.demon.co.uk... > > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message > news:_eyTg.999$Lv3.860@newsread1.news.pas.earthlink.net... >> 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. >> > > 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 > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message Yes, strings in .NET are immutable. I had a serious performance problem news:Orymvbi5GHA.2536@TK2MSFTNGP06.phx.gbl... > 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. 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.  |
|||||||||||||||||||||||
Other interesting topics