• (nodebb)

    Correction, depending on the version, concatenation of multiple strings is likely to be emitted as a call to the static string.Concat. So, we have only 3 string instances per execution of this line. But yeah. Dumb and dumber levels of dumb here

  • TheCPUWizard (unregistered)

    Just a note: The execution of the code takes the time.... The fact that lots of temporaries (which are immediately "unreachable" is largely (or at least should be) irrelevant. The time a GC (full) takes to complete is based on the number of live reachable objects it must inspect and potentially move at each time. In an ultra simplistic case, create 10000 temporary strings, but hold no references: the GC is basically just a pointer reset; On the other hand put those 10000 items into something that is 'reachable' and the GC time will increase dramatically as they all must be processed into the next generation heap and all references adjusted accordingly.

  • (nodebb) in reply to Mr. TA

    However you should no longer use string.Concat (or string.Format) at all but $ because it will analyze the string and optimize it including precompiling composition formats for best performance.

  • (nodebb)

    The faster computers become, the longer it takes them to finish a job it seems. "Performance" is no longer a priority, and developers are taught that "maintainable" code is better than "fast" code. While I (for the most part) agree with that, this code is the worst of both worlds.

  • (nodebb)

    Given that this is executing in the context of a web page, the simple GC scenario posited by TheCPUWizard will not be what's happening inside that AppDomain. Whole lotta other allocate/deallocate noise going on simultaneously.

    Unrelated to that ... Looking at the contents of the string they're generating, I suspect they are building an XLSX on the fly. Which makes me wonder how many clerks pull that file using the exact same parameters each day? Lots I bet.

  • (nodebb)

    I agree, and using Excel is an equally horrible WTF. Just.... don't.

  • Dr, Pepper (unregistered)

    When doing code reviews that involve loops, I often castigate my fellow developers for over-optimizing loops, because we have processors that run at 3GH or better; for most cases having a loop that is not performant (or could perform better) is not as important as having a loop that is easy for a human to understand.

    But when the loop is executed hundreds of thousands of times? Yeah, maybe then.

  • Foo AKA Fooo (unregistered) in reply to TheCPUWizard

    But doesn't more (temporary) allocations mean that GC needs to run more often, visiting all live objects each time?

  • (nodebb)

    I'm kind of surprised that the slow performance turned out to be the strings, I'd have guessed the main problem was the 200,000+ calls to the IO method.

  • (nodebb) in reply to Foo AKA Fooo

    Yes... except the GC won't be being run simply after a fixed number of allocations. Application servers tend to use a mixture of GC strategies so that temp objects are cleaned up reasonably promptly without paying the cost in obvious places. In short, a few extra allocations won't make much difference... unless you're calling code like this over and over.

    Making sure you're building strings optimally inside your output loop is one of the easier performance wins in a great many applications.

Leave a comment on “A Memory of Strings”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article