...Or, maybe he should write the string handling in an efficient way and see
if it works without GC.Collect? IMHO (and in the humble opinion of a great
many developers including those at MS), calling GC.Collect should be a last
resort and not a normal part of the programming process.
I think we agree on GC.Collect's place in production applications, my point
only being it's useful to diagnose whether the garbage collector is actually
the problem.
As for StringBuilder: it will make the string operations slightly more efficient
up until it gets assigned to Textbox1.Text, at which point it becomes a string
(a very long one, by the sound of it...)
The cumulative result of doing that assignment 22,000 times, or even
23,000 times, is.. a lot of orphaned string references coming from Textbox
itself to be cleaned up - even with StringBuilder.
As for StringBuilder: it will make the string operations slightly more
efficient
up until it gets assigned to Textbox1.Text, at which point it becomes a string
(a very long one, by the sound of it...)
The cumulative result of doing that assignment 22,000 times, or even
23,000 times, is.. a lot of orphaned string references coming from Textbox
itself to be cleaned up - even with StringBuilder.
Aren't you assuming that the text property of a textbox is immutable like
the string that you pass to it? I'm not sure that it is. I think that the
text property is mutable in the same way that the StringBuilder is. The
string builder takes in a string value as an argument and then holds that
value in a mutable way. My understanding of the textbox's text property is
that it does the same?
So, if I were to change the text property of a textbox 10 times, I
*wouldn't* necessarily have created 10 different strings on the heap, 9 of
which would wind up being orphaned.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.