say what?
On Feb 6, 1:28 am, sushant mundkar <[email protected]> wrote: > You need to try out one again thank you sushant mundkar > > On 2/5/09, jay <[email protected]> wrote: > > > > > > > > > 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 - > > -- > sushant- Hide quoted text - > > - Show quoted text -
