How to efficiently chunk long string

Hi Anony,

Why are you sending a real "language.vb" question also to the dotnet.general
group.
The language.vb newsgroup is one of the groups where you get always an
answer.

Your answer (sended from the general group by the way),

For your problem is the stringbuilder

Roughly written beneath

I hope it helps?

Cor
\\\\
dim sb as System.text.Stringbuilder
Dim iPos as Integer
For i to SourceString.Length - lineLength - 1 'check this yourself I did not
check it at all
sb.append(Sour..... et & vbCrLf ) 'you can can keep that & that
goes inline
next
dim mystring as string = sb.tostring
///

I'm trying to chunk a long string SourceString into lines of LineLength
using this code:

Dim sReturn As String = ""
Dim iPos As Integer = 0
Do Until iPos >= SourceString.Length - LineLength
sReturn += SourceString.Substring(iPos, LineLength) + vbCrLf
iPos += LineLength
Loop
sReturn += SourceString.Substring(iPos)

It's OK if the SourceString is less than 1 mb. But if it's over 5 mb, the
cost of time and machine resource is intolerable.
Does anyone has a better idea or a routine dealing with large SourceString?

Thanks and regards,
Anony

Nov 20 '05 #2

Anony

Thanks Cor for the very good idea, improved performance 100X!

I put the code here just in case someone needs:

Dim SB As New System.Text.StringBuilder
Dim iPos As Integer
For iPos = 0 To SourceString.Length - LineLength Step LineLength
SB.Append(SourceString.Substring(iPos, LineLength) + vbCrLf)
Next
SB.Append(SourceString.Substring(iPos))
Dim sReturn As String = SB.ToString
SB = Nothing

No more dotnet.general, thanks for the advice.

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O%***************@TK2MSFTNGP12.phx.gbl...

Hi Anony,

Why are you sending a real "language.vb" question also to the dotnet.general group.
The language.vb newsgroup is one of the groups where you get always an
answer.

Your answer (sended from the general group by the way),

For your problem is the stringbuilder

Roughly written beneath

I hope it helps?

Cor
\\\\
dim sb as System.text.Stringbuilder
Dim iPos as Integer
For i to SourceString.Length - lineLength - 1 'check this yourself I did not check it at all
sb.append(Sour..... et & vbCrLf ) 'you can can keep that & that
goes inline
next
dim mystring as string = sb.tostring
///
I'm trying to chunk a long string SourceString into lines of LineLength
using this code:

Dim sReturn As String = ""
Dim iPos As Integer = 0
Do Until iPos >= SourceString.Length - LineLength
sReturn += SourceString.Substring(iPos, LineLength) + vbCrLf
iPos += LineLength
Loop
sReturn += SourceString.Substring(iPos)

It's OK if the SourceString is less than 1 mb. But if it's over 5 mb, the cost of time and machine resource is intolerable.
Does anyone has a better idea or a routine dealing with large

SourceString?

Thanks and regards,
Anony

Nov 20 '05 #3

ANony,
A couple of improvements:

Dim SB As New System.Text.StringBuilder(SourceString.Length + SourceString.Length \ (lineLength + 1) * 2 ) Dim iPos As Integer
For iPos = 0 To SourceString.Length - LineLength Step LineLength
SB.Append(SourceString.Substring(iPos, LineLength))
SB.Append(vbCrLf)
Next
SB.Append(SourceString.Substring(iPos))
Dim sReturn As String = SB.ToString
Using StringBuilder.Append twice avoids all the temporary strings caused by
concatenating ControlChars.CrLf to the substring for each line (the GC will
be grateful). Remember one of the major reasons to use StringBuilder in the
first place is to avoid the temporary strings being allocated with
concatenations.

Including the expected length on the StringBuilder constructor, avoids
reallocating its buffer (again the GC will be grateful). Note I am setting
the StringBuilder's capacity to the same length as the SourceString, plus 2
characters (cr & lf) for each line, plus an extra line for rounding down on
the integer division.

By avoiding extra the substring allocations & buffer reallocations you
should see better then 100X improvement!

Hope this helps
Jay

"Anony" <An***@Nepal.NL> wrote in message
news:c8**********@news3.tilbu1.nb.home.nl... Thanks Cor for the very good idea, improved performance 100X!

I put the code here just in case someone needs:

Dim SB As New System.Text.StringBuilder
Dim iPos As Integer
For iPos = 0 To SourceString.Length - LineLength Step LineLength
SB.Append(SourceString.Substring(iPos, LineLength) + vbCrLf)
Next
SB.Append(SourceString.Substring(iPos))
Dim sReturn As String = SB.ToString
SB = Nothing

No more dotnet.general, thanks for the advice.

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O%***************@TK2MSFTNGP12.phx.gbl...
Hi Anony,

Why are you sending a real "language.vb" question also to the

dotnet.general
group.
The language.vb newsgroup is one of the groups where you get always an
answer.

Your answer (sended from the general group by the way),

For your problem is the stringbuilder

Roughly written beneath

I hope it helps?

Cor
\\\\
dim sb as System.text.Stringbuilder
Dim iPos as Integer
For i to SourceString.Length - lineLength - 1 'check this yourself I did

not
check it at all
sb.append(Sour..... et & vbCrLf ) 'you can can keep that & that
goes inline
next
dim mystring as string = sb.tostring
///
I'm trying to chunk a long string SourceString into lines of LineLength using this code:

Dim sReturn As String = ""
Dim iPos As Integer = 0
Do Until iPos >= SourceString.Length - LineLength
sReturn += SourceString.Substring(iPos, LineLength) + vbCrLf
iPos += LineLength
Loop
sReturn += SourceString.Substring(iPos)

It's OK if the SourceString is less than 1 mb. But if it's over 5 mb,

the cost of time and machine resource is intolerable.
Does anyone has a better idea or a routine dealing with large

SourceString?

Thanks and regards,
Anony

Nov 20 '05 #4

Hi Jay,

What you stated was what I always was thinking (and made all my samples like
that), until we tested that some weeks ago.

My expirience was that for the inline functions the creation of a string
with *&* was faster than appending it with the stringbuilder. (While I
always extreme was doing that and therefore it took my attention).

SB.Append(SourceString.Substring(iPos, LineLength))
SB.Append(vbCrLf)
Next

My expirience is that this is faster

SB.Append(SourceString.Substring(iPos , LineLength & vbCrLf)

Cor

Nov 20 '05 #5

Cor,
It may be faster in a simply test.

However! You are also causing more work for the GC, so when the GC finally
needs to collect all those temporary strings, your app will slow down.

So is it really faster?

Hope this helps
Jay

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:u%****************@TK2MSFTNGP11.phx.gbl...

Hi Jay,

What you stated was what I always was thinking (and made all my samples like that), until we tested that some weeks ago.

My expirience was that for the inline functions the creation of a string
with *&* was faster than appending it with the stringbuilder. (While I
always extreme was doing that and therefore it took my attention).
SB.Append(SourceString.Substring(iPos, LineLength))
SB.Append(vbCrLf)
Next

My expirience is that this is faster

SB.Append(SourceString.Substring(iPos , LineLength & vbCrLf)

Cor

Nov 20 '05 #6

Jeff

Actually its not a real "language.vb" question but a .NET framework
question. The line gets blurred when dealing with a multi-language
framework. I don't mind the question in both places. Just my two cents...
"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O%***************@TK2MSFTNGP12.phx.gbl...

Hi Anony,

Why are you sending a real "language.vb" question also to the dotnet.general group.
The language.vb newsgroup is one of the groups where you get always an
answer.

Your answer (sended from the general group by the way),

For your problem is the stringbuilder

Roughly written beneath

I hope it helps?

Cor
\\\\
dim sb as System.text.Stringbuilder
Dim iPos as Integer
For i to SourceString.Length - lineLength - 1 'check this yourself I did not check it at all
sb.append(Sour..... et & vbCrLf ) 'you can can keep that & that
goes inline
next
dim mystring as string = sb.tostring
///
I'm trying to chunk a long string SourceString into lines of LineLength
using this code:

Dim sReturn As String = ""
Dim iPos As Integer = 0
Do Until iPos >= SourceString.Length - LineLength
sReturn += SourceString.Substring(iPos, LineLength) + vbCrLf
iPos += LineLength
Loop
sReturn += SourceString.Substring(iPos)

It's OK if the SourceString is less than 1 mb. But if it's over 5 mb, the cost of time and machine resource is intolerable.
Does anyone has a better idea or a routine dealing with large

SourceString?

Thanks and regards,
Anony

Nov 20 '05 #7

> Cor,

It may be faster in a simply test.

However! You are also causing more work for the GC, so when the GC finally
needs to collect all those temporary strings, your app will slow down.

So is it really faster?

That collecting goes in null time. Therefore I think the work of the GC
should not be an isue in making a right program.

I surelly would not have stated this, because I was the first in this
newsgroup who extremly did use that code as you showed now, and recognise
with that tests that my idea about this was wrong. (Not extreme however it
was recognizable)

I myself find it still nicer code by the way with that append.

Cor

Nov 20 '05 #8

HI Jeff,

Everything is a framework question when it is dotnet.

And as I told I answered Anony from the general group, in this case it goes
about how to use a program language with the framework, for that are 4
newsgroup.

I am probably the one who encourages the most crossposting in the dotnet
newsgroups, however here it is to obvious a language question in my opinion.

Cor

Nov 20 '05 #9

Jeff

Hey Cor,

Everything is a framework question when it is dotnet.
Not really. VB.NET has different issues than C#, and vice versa. Does VB.NET
have a using clause? Does C# have an AddHandler function. These are language
specific items.
however here it is to obvious a language question in my opinion.
The string and stringbuilder are part of the .NET framework, not part of the
languages themselves. The problem the user posted is relevant to anyone
trying to do the same thing regardless of language. The answer you provided
would work regardless of .NET language, correct?

Actually I think that the posting could have been sent to .NET VB and .NET
Framework newsgroups.

Jeff

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:eR*************@TK2MSFTNGP11.phx.gbl... HI Jeff,

Everything is a framework question when it is dotnet.

And as I told I answered Anony from the general group, in this case it goes about how to use a program language with the framework, for that are 4
newsgroup.

I am probably the one who encourages the most crossposting in the dotnet
newsgroups, however here it is to obvious a language question in my opinion.
Cor

Nov 20 '05 #10

Cor Ligthert <no**********@planet.nl> wrote:

Everything is a framework question when it is dotnet.

And as I told I answered Anony from the general group, in this case it goes
about how to use a program language with the framework, for that are 4
newsgroup.

I am probably the one who encourages the most crossposting in the dotnet
newsgroups, however here it is to obvious a language question in my opinion.

I think you have a much broader idea of what counts as a language
question than I do, Cor. I agree with the others - it's a framework
question. The basic answer is "use a StringBuilder rather than string
concatenation" and there's nothing VB.NET-specific in that.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 20 '05 #11

Hi Jeff,

In the language.vb net group has Anony disconnected the newsgroup
microsoft.public.dotnet.general

There he has answers from not only me.

In the dotnet general group with exception from mine answer there are only
troll answers.

I hope this clears it.

Cor

Nov 20 '05 #12

Jeff

> I hope this clears it.

No it doesn't and you didn't answer my question.

The answer you provided would work regardless of .NET language, correct? The
string and stringbuilder are part of the framework and not the VB.NET
language correct?

This is not only a VB.NET question(I agree it should be posted in VB.NET),
its a .NET Framework question also, and you could add on .NET framework
performance newsgroup also. I think the thread you guys have here would be
helpful for anyone using the string and stringbuilder framework classes.

I hope this is clear?

Jeff

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O9**************@TK2MSFTNGP12.phx.gbl...

Hi Jeff,

In the language.vb net group has Anony disconnected the newsgroup
microsoft.public.dotnet.general

There he has answers from not only me.

In the dotnet general group with exception from mine answer there are only
troll answers.

I hope this clears it.

Cor

Nov 20 '05 #13

Anony

Thanks Both,

It's indeed over 100X faster, especially process large file string over 10
Mb.

However, this SB reminds me an old issuse in VB6. I did the same thing in
VB6 for about 10 Mb file string more than just one or two "Append", but very
very costly.
So, my question: how can I do this without SB (i.e. in VB6)?
Thanks and regards

Nov 20 '05 #14

Hi Antony

Do you mean that changing that string + vbcrlf to 2 seperate appends, did
make it again 100 times faster so that it is now 10000 times faster than
before?

What is happeng is easy, a string is immutable, which mean that every change
in a string will result in a new string. I think that you can immaging what
happens in the memory when the strings become longer and longer.

The stringbuilder does that not but let us say appends everytime. This is
especially important of course with long strings.

Therefore I am suprissed that adding only vbcrlf to a string will change the
behaviour. However I agree that when the first string is a real long string,
that that can possible change the performance (something I think about now),
I did test it only with short strings.

As far as I know is there nothing like the stringbuilder in VB6.

Cor

Nov 20 '05 #15

Anony

Hi Cor,

I couldn't notice the difference between string + vbCrLf or one more vbCrLf
in just a few sec. comparing that it was over 10 min without SB!
The allocated capacity has limited some memory usage, perhaps it increases
the speed too.

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

Hi Antony

Do you mean that changing that string + vbcrlf to 2 seperate appends, did
make it again 100 times faster so that it is now 10000 times faster than
before?

What is happeng is easy, a string is immutable, which mean that every change in a string will result in a new string. I think that you can immaging what happens in the memory when the strings become longer and longer.

The stringbuilder does that not but let us say appends everytime. This is
especially important of course with long strings.

Therefore I am suprissed that adding only vbcrlf to a string will change the behaviour. However I agree that when the first string is a real long string, that that can possible change the performance (something I think about now), I did test it only with short strings.

As far as I know is there nothing like the stringbuilder in VB6.

Cor

Nov 20 '05 #16

Cor Ligthert <no**********@planet.nl> wrote:

In the dotnet general group with exception from mine answer there are only
troll answers.

That's a scandalous assertion, and one which frankly warrants an
apology to the many people who help people daily in the dotnet.general
group and who you've just insulted as being trolls.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 20 '05 #17

Larry Serflaten

"Anony" <An***@Nepal.NL> wrote

It's indeed over 100X faster, especially process large file string over 10
Mb.

However, this SB reminds me an old issuse in VB6. I did the same thing in
VB6 for about 10 Mb file string more than just one or two "Append", but very
very costly.
So, my question: how can I do this without SB (i.e. in VB6)?

There was a thread earlier this year (IIRC) in ...vb.general.discussion about
pre-allocating a string to gain performance. You can mimic the string builder
in VB6 using pre-allocation and the Mid command to insert text into the string.
It turns out, if you're writing to a file, however, you might just as well add your
lines to the file as opposed to building a large string to write all at once. The
file buffer or cache, is more than able to keep up with the task and flush the
data to disk when needed. It was a good idea to explicitly set the Len to 4096
when opening the file, to provide sufficient buffering.

I believe Karl Perterson has such a String Builder class for classic VB on his
site at www.mvps.org/vb/

LFS

Nov 20 '05 #18

Anony

Thanks Larry,

I'll try to find the class from mvps and have a try.

Thanks for the suggestion. I do that in two cases:
1. get lines from socket, build all up, decode them before save to disk
2. read from disk, encode it, chunk into lines, then send to socket

"Larry Serflaten" <se*******@usinternet.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"Anony" <An***@Nepal.NL> wrote
It's indeed over 100X faster, especially process large file string over 10 Mb.

However, this SB reminds me an old issuse in VB6. I did the same thing in VB6 for about 10 Mb file string more than just one or two "Append", but very very costly.
So, my question: how can I do this without SB (i.e. in VB6)?
There was a thread earlier this year (IIRC) in ...vb.general.discussion

about pre-allocating a string to gain performance. You can mimic the string builder in VB6 using pre-allocation and the Mid command to insert text into the string. It turns out, if you're writing to a file, however, you might just as well add your lines to the file as opposed to building a large string to write all at once. The file buffer or cache, is more than able to keep up with the task and flush the data to disk when needed. It was a good idea to explicitly set the Len to 4096 when opening the file, to provide sufficient buffering.

I believe Karl Perterson has such a String Builder class for classic VB on his site at www.mvps.org/vb/

LFS

Nov 20 '05 #19

Cor,
"Null time" what is null time?

I sincerely hope you are not suggesting that time spent in the GC really
doesn't matter. You do realize that the major reason the StringBuilder
sample is faster then the String Concatenation sample because StringBuilder
is not create temporary strings that the GC need to take care of.

If you have not tried the original code & the StringBuilder code in CLR
Profiler you may want to profile all three samples to see the amount of time
being spent in the GC.

Thanks for understanding.
Jay

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:Oi*************@TK2MSFTNGP10.phx.gbl...

Cor,
It may be faster in a simply test.

However! You are also causing more work for the GC, so when the GC finally needs to collect all those temporary strings, your app will slow down.

So is it really faster?

That collecting goes in null time. Therefore I think the work of the GC
should not be an isue in making a right program.

I surelly would not have stated this, because I was the first in this
newsgroup who extremly did use that code as you showed now, and recognise
with that tests that my idea about this was wrong. (Not extreme however it
was recognizable)

I myself find it still nicer code by the way with that append.

Cor

Nov 20 '05 #20

Anony,
To really see a difference you would need to repeat the outer loop multiple
times. A single pass over the loop may not show any significant measurable
difference...

Rather then simply timing the loop, you can use the CLR Profiler to see all
the extraneous string allocations that I was referring to.

Info on the CLR Profiler:
http://msdn.microsoft.com/library/de...nethowto13.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

Hope this helps
Jay

"Anony" <An***@Nepal.NL> wrote in message
news:c8**********@news3.tilbu1.nb.home.nl...

Hi Cor,

I couldn't notice the difference between string + vbCrLf or one more vbCrLf in just a few sec. comparing that it was over 10 min without SB!
The allocated capacity has limited some memory usage, perhaps it increases
the speed too.

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
Hi Antony

Do you mean that changing that string + vbcrlf to 2 seperate appends, did make it again 100 times faster so that it is now 10000 times faster than
before?

What is happeng is easy, a string is immutable, which mean that every

change
in a string will result in a new string. I think that you can immaging

what
happens in the memory when the strings become longer and longer.

The stringbuilder does that not but let us say appends everytime. This is especially important of course with long strings.

Therefore I am suprissed that adding only vbcrlf to a string will change

the
behaviour. However I agree that when the first string is a real long

string,
that that can possible change the performance (something I think about

now),
I did test it only with short strings.

As far as I know is there nothing like the stringbuilder in VB6.

Cor

Nov 20 '05 #21

Cor,
I agree with Jon on this one!

Jay

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O9**************@TK2MSFTNGP12.phx.gbl...

Hi Jeff,

In the language.vb net group has Anony disconnected the newsgroup
microsoft.public.dotnet.general

There he has answers from not only me.

In the dotnet general group with exception from mine answer there are only
troll answers.

I hope this clears it.

Cor

Nov 20 '05 #22

Cor,
By the way, here is one of many MSDN articles on writing programs that
perform well, including using multiple Append's over string concatenation
when using the StringBuilder.

http://msdn.microsoft.com/architectu...l/scalenet.asp

The above article was published last week.
For a plethora of other articles on writing code that performs well see:

http://msdn.microsoft.com/library/de...anagedcode.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

http://msdn.microsoft.com/library/de...vbnstrcatn.asp

http://msdn.microsoft.com/library/de...tchperfopt.asp

http://msdn.microsoft.com/library/de...tperftechs.asp

Hope this helps
Jay

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:Oi*************@TK2MSFTNGP10.phx.gbl...

Cor,
It may be faster in a simply test.

However! You are also causing more work for the GC, so when the GC finally needs to collect all those temporary strings, your app will slow down.

So is it really faster?

That collecting goes in null time. Therefore I think the work of the GC
should not be an isue in making a right program.

I surelly would not have stated this, because I was the first in this
newsgroup who extremly did use that code as you showed now, and recognise
with that tests that my idea about this was wrong. (Not extreme however it
was recognizable)

I myself find it still nicer code by the way with that append.

Cor

Nov 20 '05 #23

Jay,

For me was frustrating that I always send to OP's the code exactly as you
had made now, than there are others who use partially the connection in a
string. I do not start with them a discussion about that anymore.

You would have maybe seen that (it is a time ago I sand that) in my example
how to build a CSV file from a dataset using the stringbuilder, there I have
done that extremely with the stringbuilder.append. However I got the idea
that nobody did understand why I did that.

I tested it some weeks ago and saw that the results from doing that was null
or almost null when it was the inline part, it seems to me as something that
plays now in the ADONET group with the datatable.select and the
dataview.rowfilter, that seems that there are things done with some
invisible caching.

Therefore, I tried to tell the OP the essentials from the change in his code
and did not go for my own hobbyhorse.

Than there came a correction from you in the way as I normally always do it
as a message to the OP.

I did not understand why you did that. You could have started a discussion
in the rowe where I did give my advice to the OP as well. When you know how
I act in that case, you would have seen that I would have tested that deeper
again.

In addition, the GC is not a part of the code for me. A good program has
nothing to do with how the operating system acts today in my opinion (When
it are minor things). When you do not agree that with me, than we have in
that a different meaning, which is in my opinion no problem.

Thanks for the link I check it.

Cor

Nov 20 '05 #24

Hi Jay,

In the dotnet general group with exception from mine answer there are only troll answers.

You mean knowing that I am a regular from the general group you do as Jon
not read it in its context as it was meant.

In the dotnet general group with exception from mine answer there are *in
this thread* only
troll answers

When you keep that, I will place a general excuse in the dotnet general
group referencing to you and Jon, because I never would insult in general
the visitors there.

Cor

Nov 20 '05 #25

Cor Ligthert <no**********@planet.nl> wrote:

You mean knowing that I am a regular from the general group you do as Jon
not read it in its context as it was meant.

In the dotnet general group with exception from mine answer there are *in
this thread* only troll answers
If you'd said that, I would have disagreed (pointing out that the
question is *not* a VB-specific one isn't trolling) but I wouldn't have
been as affronted.

It certainly wasn't clear that you meant that originally though. If
you'd just corrected yourself much earlier, it would have saved a lot
of hassle.
When you keep that, I will place a general excuse in the dotnet general
group referencing to you and Jon, because I never would insult in general
the visitors there.

Well that's *certainly* not how it came across, to me at least.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 20 '05 #26

Anony

Thanks Jay,

I tested a couple of rounds, each 20 passes between these two cases:

1.
SB.Append(SourceString.Substring(iPos, LineLength) + vbCrLf)

2.
SB.Append(SourceString.Substring(iPos, LineLength))
SB.Append(vbCrLf)

The SourceString is encoded, over10 Mb, LineLength = 76.
The time ticker difference for case 1 is about 32,000,000; and for case 2
about 21,000,000.
So, I'd say SB.Append(vbCrLf) is faster than + vbCrLf.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uS****************@TK2MSFTNGP09.phx.gbl...

Anony,
To really see a difference you would need to repeat the outer loop multiple times. A single pass over the loop may not show any significant measurable
difference...

Rather then simply timing the loop, you can use the CLR Profiler to see all the extraneous string allocations that I was referring to.

Info on the CLR Profiler:
http://msdn.microsoft.com/library/de...nethowto13.asp
http://msdn.microsoft.com/library/de...anagedapps.asp
Hope this helps
Jay

Nov 20 '05 #27

> > You mean knowing that I am a regular from the general group you do as
Jon

not read it in its context as it was meant.
If you'd said that, I would have disagreed

Do you mean that I am not a regular from the dotnet.general newsgroup?

Nov 20 '05 #28

Hi Anony,

Thanks from me, now I do not have to test it and go back to my previous
methods, which is the append from every thing and nothing inline.

(By the way using that + is not really VB it is the &.

I was as well using the +. Now I use because Herfried did give almost
everytime a reply when I used that in my samples the &. I think most VB
people are used to it, which makes talking in this newsgroup easier when the
& is used.

Cor

Nov 20 '05 #29

Hi Jay,

I see it sit very deep in my mind, here a message I once got from someone
who had seldom had critique on me, even when it was needed. (I do not say he
was not right with this message, however it showed how much I was using it)

:-)

Hi Cor,

Sorry if I'm being a damp squib here but a StringBiulder for a single
concat (or even a few small ones) gives no advantage. It comes into its own
when it reduces the number and/or size of temporary strings by a fairly
decent
amount - such as within loops. The savings are due to reduced amounts of
copying and reduced GC activity.

Regards,
Fergus

Nov 20 '05 #30

Hi Jay,

A lot of different questions.

That link is very intresting a lot of stuf and surely very intressting,
however it gives again questions.

One of them that is in the text (The other is about caching the dataset what
is in conflict with something what goes in the ADONET newsgroup and has to
do with concurrency).

Call Close or Dispose on Classes that Support It
If the managed class you use implements Close or Dispose, call one of these
methods as soon as you are finished with the object. Do not simply let the
resource fall out of scope. If an object implements Close or Dispose, it
does so because it holds an expensive, shared, native resource that should
be released as soon as possible.

This means in my opinion by instance that every control has to be disposed
because that has that method.

What do you think about this text?

Cor

Nov 20 '05 #31

Cor,

This means in my opinion by instance that every control has to be disposed
because that has that method.

What do you think about this text? Do you mean control as in Windows Forms Control?

My understanding is that when you Dispose form, it will implicitly Dispose
every Control.

Remember for modeless forms (Form.Show) Dispose is called when you call
Close, where as for modal forms (Form.ShowDialog) you need to explicitly
call Dispose.

Hope this helps
Jay

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl... Hi Jay,

A lot of different questions.

That link is very intresting a lot of stuf and surely very intressting,
however it gives again questions.

One of them that is in the text (The other is about caching the dataset what is in conflict with something what goes in the ADONET newsgroup and has to
do with concurrency).

Call Close or Dispose on Classes that Support It
If the managed class you use implements Close or Dispose, call one of these methods as soon as you are finished with the object. Do not simply let the
resource fall out of scope. If an object implements Close or Dispose, it
does so because it holds an expensive, shared, native resource that should
be released as soon as possible.

This means in my opinion by instance that every control has to be disposed
because that has that method.

What do you think about this text?

Cor

Nov 20 '05 #32

Hi Jay,

That was my understanding as well, however I do not like text which makes my
doubt about the quality of the article while it looks overall so very good,
(especially the part of the GC).

Cor

My understanding is that when you Dispose form, it will implicitly Dispose
every Control. Remember for modeless forms (Form.Show) Dispose is called when you call
Close, where as for modal forms (Form.ShowDialog) you need to explicitly
call Dispose.

Nov 20 '05 #33

Cor Ligthert <no**********@planet.nl> wrote:

You mean knowing that I am a regular from the general group you do as
Jon not read it in its context as it was meant.
If you'd said that, I would have disagreed

Do you mean that I am not a regular from the dotnet.general newsgroup?

That was some constructive snipping. Let's see what I *actually*
posted:
<quote> You mean knowing that I am a regular from the general group you do as Jon
not read it in its context as it was meant.

In the dotnet general group with exception from mine answer there are *in
this thread* only troll answers

If you'd said that, I would have disagreed (pointing out that the
question is *not* a VB-specific one isn't trolling) but I wouldn't have
been as affronted.
</quote>

It's clear from my post that what I would have disagreed with was the
idea that the only posts in this thread other than yours are troll
posts.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 20 '05 #34

Jeff

> In the dotnet general group with exception from mine answer there are *in

this thread* only
troll answers
I think what Jon was disagreeing with, and a point that I disagree with also
is, "this thread there only troll answers".

You directed a thread of discussion away from this newsgroup to the VB.NET
newsgroup, a thread that have every right being here since its main topic
was .NET Framework classes and a thread that I find valuable to myself even
though I don't use VB.NET. You then say there is only trolls in this thread.
The only thing I can be convicted of in my eyes is showing concern, and you
labelled me a troll. Real nice.
"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2*****************@TK2MSFTNGP09.phx.gbl... Hi Jay,
In the dotnet general group with exception from mine answer there are only troll answers.

You mean knowing that I am a regular from the general group you do as Jon
not read it in its context as it was meant.

In the dotnet general group with exception from mine answer there are *in
this thread* only
troll answers

When you keep that, I will place a general excuse in the dotnet general
group referencing to you and Jon, because I never would insult in general
the visitors there.

Cor

Nov 20 '05 #35

> It's clear from my post that what I would have disagreed with was the

idea that the only posts in this thread other than yours are troll
posts.

So you do agree now that you knew from the first moment that it was about
this thread and you where only insulting me from things I never would do,
and did construct arguments which where not based on truth.

That is often with kids who know that there own case is weak, than they
start insulting people from things that others know that those people never
would do.

However I always try to be polite, this is my last message in this thread,
it shows by its length and the fact that there is nothing new added (in this
thread) by the contributers in this thread from the dotNet.general group
after my first message in that news group, that I am right.

In the language.vb newsgroup it had for me much value because Anony did some
tests, which gave at least me some new insight.

When you want to learn something from it, the language.vb group is a public
newsgroup, so why not have a look at it.

By the way, I did not redirect something, that was Anony's own decision; I
did only give him an advice.

Nov 20 '05 #36

Jeff

Man your logic is warped. You are the one who started the insulting with the
troll comment. You are the one who gave him the idea to cut off the thread
here. If you did not give him the advice the thread would have grown here
and VB.NET with none of our comments added on! Plus it would have been a lot
shorter thread if you had honored our request to not redirect people away
from this news group.

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:e2**************@TK2MSFTNGP11.phx.gbl...

It's clear from my post that what I would have disagreed with was the
idea that the only posts in this thread other than yours are troll
posts.
So you do agree now that you knew from the first moment that it was about
this thread and you where only insulting me from things I never would do,
and did construct arguments which where not based on truth.

That is often with kids who know that there own case is weak, than they
start insulting people from things that others know that those people

never would do.

However I always try to be polite, this is my last message in this thread,
it shows by its length and the fact that there is nothing new added (in this thread) by the contributers in this thread from the dotNet.general group
after my first message in that news group, that I am right.

In the language.vb newsgroup it had for me much value because Anony did some tests, which gave at least me some new insight.

When you want to learn something from it, the language.vb group is a public newsgroup, so why not have a look at it.

By the way, I did not redirect something, that was Anony's own decision; I
did only give him an advice.

Nov 20 '05 #37