Fast string operations

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Chad Myers

    #16
    Re: Fast string operations

    It is a very big app. And there are two main reasons for string usage:

    1.) Much frequently-used data is cached in memory. This accounts for a
    large, static memory block. However, due to legacy conditions, when we do
    cache lookups from the legacy apps, they may pass in strings with whitespace
    padding and such, so we have to trim before looking in the Hashtable.
    Unfortunately, until we can completely get rid of the legacy apps, we have
    to deal with the trimming.

    2.) Since it's a CRM app, there are lots and lots and lots of strings.
    Almost everything is string data... customer names, phone numbers,
    addresses, customer interaction logs, phone logs, email logs, etc, etc, etc.
    The vast majority (I'd say 70+%) of the data in the database (and thus data
    that gets passed around through our app) are string data.

    There isn't a lot of concatenation (well, maybe on the ASP side, but that
    has no affect on .NET gen2 heap size) and we're cautious about using
    StringBuilders and such.

    -c


    "KH" <KH@discussions .microsoft.com> wrote in message
    news:C64637CA-28B1-46FF-9CA5-A4F7198779DB@mi crosoft.com...[color=blue]
    > Array looping: The CLR has an optimization to remove bounds checking under
    > certain conditions, mainly your basic for loop using Array.Length as the
    > condition:
    >
    > for (int i=0; i < myarray.Length; ++i)
    > {
    > // presumably playing with the indexer or re-assigning the array
    > variable
    > // here would disable the optimization, but I don't really know.
    > }
    >
    > Anyways I don't know what your app is but it must be mighty big to be so
    > worried about string performance. It's usually over-use of strings that
    > causes problems, like building strings by conditinally concatenating them,
    > stuff like that that people don't realize causes a new instance of string
    > to
    > be created with EACH operation:
    >
    > string str1 = " ABC";
    > string str2 = "DEF ";
    > string str3 = (str1 + str2).ToLower() .Trim(); // 3 Strings created here
    >
    > If that's the real issue you might look into the StringBuilder class,
    > which
    > is mutable unlike String.
    >
    > - KH[/color]


    Comment

    • Chad Myers

      #17
      Re: Fast string operations

      To all who posted on the array bounds: Thank you!

      That helps a lot. I'll try the IsWhitespace as well as the array loops that
      Nicholas suggested. I'm sure i'll find that one way works better in some
      situations, and the other works better in others.

      Thanks to all,
      Chad

      "Samuel R. Neff" <inforeliance@n ewsgroup.nospam > wrote in message
      news:cucs915qv7 5t9i3v3kvsdu4et b4tntgi3p@4ax.c om...[color=blue]
      >
      > Array bound checking in a loop is optimized such that the bounds are
      > only verified once outside the loop when the JIT knows for sure that
      > every array index within the loop will be valid. This is the case
      > when looping over elements in an array (a built-in array, not a
      > collection) and only using the loop variable to index into the array
      > and not another variable or calculation.
      >
      > Sam
      >
      >
      > On Wed, 01 Jun 2005 21:35:01 GMT, "Chad Myers"
      > <cmyers@N0.SP4M .austin.rr.com> wrote:
      >[color=green]
      >>Nicholas,
      >>
      >>Looping: I thought looping over arrays in managed code was "slow"
      >>(relatively speaking) because of all the bounds checking and whatnot. This
      >>is why people use unsafe code now and then to use pointer arithmetic to
      >>loop
      >>over arrays without all the unnecessary bounds checking.
      >>[/color]
      >[/color]


      Comment

      • Jon Skeet [C# MVP]

        #18
        Re: Fast string operations

        Chad Myers <cmyers@N0.SP4M .austin.rr.com> wrote:[color=blue]
        > Looping: I thought looping over arrays in managed code was "slow"
        > (relatively speaking) because of all the bounds checking and whatnot. This
        > is why people use unsafe code now and then to use pointer arithmetic to loop
        > over arrays without all the unnecessary bounds checking.[/color]

        It's not particularly slow, but it's actually irrelevant to what
        Nicholas was suggesting - no arrays are created when you either use the
        indexer or foreach.

        --
        Jon Skeet - <skeet@pobox.co m>
        Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.

        If replying to the group, please do not mail me too

        Comment

        Working...