• Herman (unregistered)

    Performance arguing people, lend me your ears er... eyes.

    The performance difference between StringBuilder and simple concatenation is minimal when you're talking about a couple of hundreds.

    It's start getting interesting when you using loops, and loops in loops. Generally af you'r looping to add stuff, use a StringBuilder. With the minimal performance difference it's way nicer and more scalable.

    The biggest difference between StringBuilder and concatenation is memory usage. Concatenation will copy a string with every addition, hogging up memory until GC. StringBuilder will not.

    That is way StringBuilder is considered the better practice when combining more than [insert number] strings.

  • (cs)

    And concatenation in one statement will allocate memory just once anyway. What is more it will join string literals together which will result in even better performance.

  • Level 2 (unregistered) in reply to Bobbo
    Bobbo:
    Anonymous:
    And to the person who wanted to see my test routines, I'll gladly share them with you but you'll have to sign our NDA.

    Can I see this NDA please? I have my agreement-signing pen here ready to go. (It's blue ink, I'm assuming that's okay?)

    Of course not. The NDA falls under the NDA.

  • (cs) in reply to subanark
    subanark:
    This does seem to be a mix of java and c#. Maybe the code is compiled with IKVM which allows java code to use the c# library (and thus .toString() would be an alias to .ToString())
    Cool - I had been looking all weekend for someting like IKVM. And now I have found it. Thanks
  • (cs) in reply to bjolling

    With a couple of assumptions, such as not looping, or not walking down some kinda of object structure, I find (in .net) String.Format(str, object[], IFromatProvider) a good way to handle string concats

    Under the covers, it creates a StringBuilder and uses AppendFormat.

    It's a win win, looks nicer than string concacts, and easier to use and more elegant than StringBuilder.

  • Orbstart (unregistered) in reply to Anonymous
    Anonymous:
    Well, good for you. You actually wrote code and tested something. Do you do this for every function call in every library you use? Or just the ones you're arguing about? I mean, empiricism rules and all, but generally depending on the tech documentation written by the people who actually, you know, designed and wrote the library, is a pretty reasonable thing to do.

    Whoa there sonny. You're assuming two things: a.) The library code writers are actually good at writing accurate documentation. From some of the WTFs I've seen in MSDN documentation I'd be wary. b.) The library code writers actually wrote the documentation and not some tester or tech writer.

  • (cs) in reply to Capt. Oblivious
    Capt. Oblivious:
    I don't do Java or C#. What does StringBuilder/Buffer do to increase concatenation speed? Keep references to raw data values and (maybe lazily) print them when needed? That would certainly be faster than copying arrays of chars...
    No, since that would be horribly complicated (and worse still if you had anything mutable in that lot). What they actually do is amortize the growth of the internal buffer that holds the string being built (e.g. by doubling its size whenever you want to add more data than will fit) and keeping track of how much data is actually in it. While there are scenarios where that performs poorly, they're pretty rare in practice (and you can avoid them by pre-sizing the buffer if you care enough) and as a technique it actually does exceptionally well.

    Indeed, the only thing that Java and C# get wrong is that you have to know about using these classes at all; many other language implementations do this, but hide the details from users of the language entirely.

  • (cs) in reply to Jeff Grigg

    I might also suggest that the code and database would be more maintainable if the INSERT statements listed the column names, rather than just assuming a given column order. This would make adding new columns easier -- a problem the original author pointed out.

    "Insert into wc_scanbol values(
    ...
    )"
    (But this is really a trivial point next to the unreadable generated code that abuses StringBuffer/StringBuilder instances!)
  • (cs) in reply to SatanClaus
    SatanClaus:
    Grovesy:
    brazzy:
    This has to be the uncontested winner of the "Most thorough misunderstanding of the point of StringBuffer()" award.

    Surely that would go to something I saw earlier today.. (.net so StringBuilder instead of StringBuffer)

    StringBuilder sb = new StringBuilder(); sb.Append(customer.FirstName + " " + customer.LastName + "\r\n");

    return sb.ToString();

    Do you mean StringBuffer? If so, StringBuffer is a faster way to do the operation you outlined.

    StringBuffer is java. But there is absolutely no possibility the code given above is faster than return customer.FirstName + " " + customer.LastName + "\r\n". It is conceivable that code with four append operations and no + operators could be faster, but that's not what's given above.

  • (cs) in reply to Anon
    Anon:
    Perhaps you are the one who doesn't know how to use StringBuilder correctly? If you make the StringBuilder big enough to start with, it shouldn't need to resize itself which is it's biggest drain on performance. Why don't you put your money were your mouth is and post your code?

    Repeatedly taking the .ToString() of it would also be a drain on performance, if his program were foolishly doing so.

  • (cs) in reply to Aaron
    Aaron:
    Guy who's programmed Apple IIs:
    The 2Gb RAM you bought to get the latest Windows to run is already invested. So, why not use StringBuilder and eat up that RAM?
    Another troll post? Strings are immutable and thus require a new memory allocation for the result of each and every regular concatenation. A StringBuilder uses one and only one buffer that grows dynamically, or not at all if you set the capacity parameter properly.

    In fact, the memory characteristics of concatenation vs. StringBuilder are the same as the running time characteristics; memory usage will grow more or less exponentially with the number of concatenations.

    (I say "more or less" because eventually the garbage collector will kick in and free all of that memory, except for the one result string that's still assigned, which takes up exactly as much memory as the StringBuilder would be taking up.)

    mm..actually for java there's not that much garbage collection going on with strings. java utilizes a string cache that drastically reduces garbage collection on string type objects. ever wondered why String a = "abc" String b = "abc" (a==b) //usually return true. it's very weird that this works, since the check here compares the reference. it is equal because usually you literally get the same instance.

    this is not the case for the string builder tho, so the string builders will get gced.

    i do wonder about the line "memory usage will grow more or less exponentially with the number of concatenations" while it is true that StringBuilder will allocate twice the previously allocated memory whenever it runs out of space on .Append , it still grows linearly with the number of concatenations.

  • (cs) in reply to NightDweller
    NightDweller:
    mm..actually for java there's not that much garbage collection going on with strings. java utilizes a string cache that drastically reduces garbage collection on string type objects. ever wondered why String a = "abc" String b = "abc" (a==b) //usually return true. it's very weird that this works, since the check here compares the reference. it is equal because usually you literally get the same instance.

    this is not the case for the string builder tho, so the string builders will get gced.

    That's not quite true. String constants (i.e. literals and concatenations of literals which are stored in a class's constant pool) are cached like that, but to cache a string created by concatenation of non-constant strings you have to use String.intern().

  • (cs) in reply to pjt33
    pjt33:
    NightDweller:
    mm..actually for java there's not that much garbage collection going on with strings. java utilizes a string cache that drastically reduces garbage collection on string type objects. ever wondered why String a = "abc" String b = "abc" (a==b) //usually return true. it's very weird that this works, since the check here compares the reference. it is equal because usually you literally get the same instance.

    this is not the case for the string builder tho, so the string builders will get gced.

    That's not quite true. String constants (i.e. literals and concatenations of literals which are stored in a class's constant pool) are cached like that, but to cache a string created by concatenation of non-constant strings you have to use String.intern().

    You get similar things in .net, where two variables assigned 'ABC' with string interning switched on will result in true when evaluating there references.

    The string's equality methods are overloaded (and sealed), so that it does do a value comparison on string.

    hence,

    string a = "ABC"; string b = SomeUserInputControl.Text // where the user enters "ABC"

    a == b will evaluate to true.

  • (cs) in reply to PSWorx
    PSWorx:
    He combined the memory waste of string concatenations with the uglyness of StringBuffer! It's things like this that tell you you're dealing with a genious instead of a mere mortal...
    genious indeed...
  • Shane (unregistered)

    How does string builder do all the concats faster? I understand that it will use less memory, but why would it go faster?

  • (cs) in reply to Shane

    With the concat, each concat copies both strings into the newly created target string. So the string under construction gets copied each time there's a new string tacked onto it.

    The StringBuffer only copies the string under construction when a buffer reallocation is needed; this happens log n times, where n is the number of characters, or 0 times when the size is set big enough beforehand. The strings being tacked on to the end, of course, must be copied in both situations.

  • Iceman (unregistered) in reply to Anonymous
    Anonymous:
    bjolling:
    An NDA for a simple StringBuilder performance test?
    No, it's an NDA for every single piece of work I produce at this company, irrespective of whether its a code file or a Word document. What the hell do you expect from and Aerospace and military subcontractor?

    Now I see why you work there...Coz' your head is filled with it - Air and space and a lot of BS)

  • Wongo (unregistered) in reply to Anonymous
    Anonymous:
    I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

    I seriously hope you work in the billing dept. If you are in engineering, well, at least now we know why planes crash...

  • (cs) in reply to Wongo
    Wongo:
    Anonymous:
    I know the WTF here isn't specifically about the StringBuffers but it is a WTF to see how many people misuse this functionality. I have a little performance project set up in my dev environment that I pass on to my colleagues whenever they start using StringBuilders (.NET) for string concatenation. It basically shows that you need to be making at least 100 concatenations before the StringBuilder class offers any performance increase over regular string concatenation. This is invariably an order of magnitude greater than the number of concatenations they are actually making. StringBuilder is a widely misunderstood class that, due to its misuse, is probably responsible for hindering performance more often than it improves it.

    I seriously hope you work in the billing dept. If you are in engineering, well, at least now we know why planes crash...

    Well, I would hope so to, I would hope that there is no .net code in anything that flies through the air. .net implies windows (ok, ok mono.net, but seriosuly?), windows is preemtive and i'd hate to think of the consequence of a process adjusting the flaps, suddenly being switched.

    and err, windows implies BSOD

    though could be worse, could be Java, doubt the plain would ever take off under the weight of bloated code </troll>

    Addendum (2009-01-30 11:23): Plain?! I mean Plane... oops

  • Spawnie (unregistered)

    Clearly this was generated by a recursive method. And any programmer worth his 2 cents can tell you that recursion is the most powerful and elegant programming technique in the whole universe and should, no, must be used any time it is possible to do so, provided the programmer can master is subtle complexities. This is not a WTF, this is genius at hand.

  • Quiark (unregistered)

    Looks like LISP to me..

  • (cs) in reply to Wongo

    I just have to post that I had an excellent chuckle at the "Anonymous, Aerospace, NDA, I-can-tell-you-but-then-I'd-have-to-kill-you incompetent" poster for a quite magnificent troll, well done!

    :)

  • Mizar the Magnificent (unregistered)

    I've seen some crazy sh** in my time... this takes at least a small portion of the cake.

Leave a comment on “The Great Code Spawn”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article