My apologies - I'm still figuring google groups out,
I suppose:
String.Join("",new string[]{"example","example","example"});
is equivalent to:
JoinArgs("example","example","example");
While I agree it is not much of a function, it does save me about 20
characters of code each time it is used.
On Feb 5, 1:23 pm, Cerebrus <[email protected]> wrote:
> Please reply directly to (and quote) the post that you intend to refer
> to instead of to the last post in the thread. I have never insinuated
> that any of the code you wrote is slower or faster than any of the
> code anyone else wrote.
>
> BTW, your JoinArgs isn't much of a function anyway because it only
> wraps String.Join() which can be called directly too.
>
> On Feb 5, 9:53 pm, jay <[email protected]> wrote:
>
>
>
> > I don't see how JoinArgs that I wrote is much slower since it uses the
> > stack to push the arguments, and then String.Join probably just uses
> > StringBuilder anyways I'd assume. I simply wrote it to replace
> > instances where I used a ton of string concatenations using the +
> > (plus) operator. It makes it so I can just find and replace all
> > "+" (pluses) with "," (commas) and wrap the entire thing in JoinArgs
> > ().
>
> > On Feb 5, 11:27 am, Cerebrus <[email protected]> wrote:
>
> > > Everyone has expressed their opinions, maybe I should too! ;-)
>
> > > Although I have great respect for Mahesh Chand, I think that that
> > > particular article is only for newbies. Using DateTime.Now().ToString
> > > () is hardly a good way to evaluate time elapsed. Additionally, such
> > > measurements should be in ticks, seconds are too large a unit to
> > > detect minute performance differences that only show up over hundreds
> > > of thousands of iterations. Thirdly, performance is usually gauged as
> > > an average time over a number of test repetitions. (Say, you run the
> > > code 20 times and calculate the average time taken)
>
> > > Finally, I always prefer to use the StringBuilder any time I am
> > > concatenating more than 5 strings. When using the StringBuilder, I try
> > > to guess an appropriate capacity(usually half or slightly more than
> > > estimated total capacity) for the object and use the overload that
> > > accepts a starting size. For instance,
>
> > > ---
> > > // "example" has 7 characters, so 7 x 20 will be 140 chars. Since this
> > > is a small number, I'll use 150 (round figure).
> > > // Now the StringBuilder will not need to double its buffer at all.
> > > StringBuilder sb = new StringBuilder(150)
> > > for (int i = 0; i < 20; i++)
> > > {
> > > sb.Append("example");}
>
> > > ---
>
> > > Note that I am not saying that this code is noticeably faster than
> > > concatenating 20 instances of a string. I only intend to demonstrate
> > > the *best* way to use a StringBuilder. Since the default initial
> > > capacity is only 16, it means that the StringBuilder would have to
> > > reallocate buffers atleast 4 times to suffice for a 140 char capacity.
> > > (16+32+64+128)
>
> > > Hope that clears up any persisting doubts.
>
> > > --
> > > Cerebrus.
>
> > > On Feb 5, 1:19 pm, Brandon Betances <[email protected]> wrote:
>
> > > >http://www.c-sharpcorner.com/UploadFile/mahesh/StringBuilderComp11232...
>
> > > > It's obvious he's not concatenating more than 10 strings. The proof is
> > > > in
> > > > the muri.- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
