Tech Off Thread

13 posts

Which one is faster? RegEx vs .Replace

Back to Forum: Tech Off
  • User profile image
    turrican

    Which one is faster?

    Regex.Replace(textBox1.Text, @"\r\n", "<br>", RegexOptions.IgnoreCase);

    vs

    textBox1.Text.Replace("\r\n","<br>");

  • User profile image
    W3bbo

    The replace since it's a hardcoded string function.

    The Regex will take longer since it needs to parse the regex string (even if you set RegexOptions.Compiled) then execute it in the regex string then formulate the resultant string. But if you really want to be sure, perform each iteration in a million-times iterator and time the result.

    P.S. it's "<br />" not "<br>", and verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.

  • User profile image
    turrican

    W3bbo said:
    The replace since it's a hardcoded string function.

    The Regex will take longer since it needs to parse the regex string (even if you set RegexOptions.Compiled) then execute it in the regex string then formulate the resultant string. But if you really want to be sure, perform each iteration in a million-times iterator and time the result.

    P.S. it's "<br />" not "<br>", and verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.
    Thanks! I keep forgetting it's <br />

  • User profile image
    Matthew van Eerde

    W3bbo said:
    The replace since it's a hardcoded string function.

    The Regex will take longer since it needs to parse the regex string (even if you set RegexOptions.Compiled) then execute it in the regex string then formulate the resultant string. But if you really want to be sure, perform each iteration in a million-times iterator and time the result.

    P.S. it's "<br />" not "<br>", and verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.
    > verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.

    Huh?  The regex expects a string of the form "backslash, r, backslash, n".
    Replace expects a string of the form "carriage return, line feed".

    So the use of verbatim is correct here.

  • User profile image
    W3bbo

    Matthew van Eerde said:
    W3bbo said:
    *snip*
    > verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.

    Huh?  The regex expects a string of the form "backslash, r, backslash, n".
    Replace expects a string of the form "carriage return, line feed".

    So the use of verbatim is correct here.
    Oh, I forgot that the Regex in .NET also recognises C-style escapes for newlines and carriage returns.

  • User profile image
    TommyCarlier

    W3bbo said:
    The replace since it's a hardcoded string function.

    The Regex will take longer since it needs to parse the regex string (even if you set RegexOptions.Compiled) then execute it in the regex string then formulate the resultant string. But if you really want to be sure, perform each iteration in a million-times iterator and time the result.

    P.S. it's "<br />" not "<br>", and verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.
    <br/> is only necessary in XHTML. Regular HTML does not need the backslash.

  • User profile image
    stevo_

    TommyCarlier said:
    W3bbo said:
    *snip*
    <br/> is only necessary in XHTML. Regular HTML does not need the backslash.
    Normal html won't have issues with elements that properly terminate theirself though right? personally I'd always stick to doing html like xml.. elements should either self terminate properly or have a terminating end tag, this way you just remember to always do it one way.. and right.

    Edit: unless of course this is some sort of parser or sanitizer.. in which case you'll maybe want to look for "poorly formed" variants, which I guess is what tommy was saying.

  • User profile image
    W3bbo

    TommyCarlier said:
    W3bbo said:
    *snip*
    <br/> is only necessary in XHTML. Regular HTML does not need the backslash.
    Yes, but you might as well be future-proof. XML-style self-terminating elements work fine in pretty much every SGML parser out there (according to the SGML specification the trailing '/' should be interpreted as a boolean attribute).

  • User profile image
    Yggdrasil

    Most importantly, if this is a function that is called on one textbox, or even a handful, with a non-gigantic amount of text, the difference in speed is irrelevant. Both will be far below anything the user will notice. If this is UI code you're talking about, I wouldn't bother wasting time optimizing this action.

  • User profile image
    JPBuckeye

    Yggdrasil said:
    Most importantly, if this is a function that is called on one textbox, or even a handful, with a non-gigantic amount of text, the difference in speed is irrelevant. Both will be far below anything the user will notice. If this is UI code you're talking about, I wouldn't bother wasting time optimizing this action.
    I second this concept.  Unless the comparison is going to happen millions of times the speed difference isn't necessarily important.  Premature optimization is always a bad idea.

  • User profile image
    evildictait​or

    JPBuckeye said:
    Yggdrasil said:
    *snip*
    I second this concept.  Unless the comparison is going to happen millions of times the speed difference isn't necessarily important.  Premature optimization is always a bad idea.
    On the other hand string.Replace(string, string) is semantically easier to understand than the Regex equivilent.

    Consequently it is definitely a good idea to go with the string replacement unless you have good reason not to.

  • User profile image
    Deactivated User

    Comment removed at user's request.

  • User profile image
    JackAnd80

    Programous said:

    Given two ways of doing something, regex is almost always slower.

    I agree that regex is very helpful but works very slowly and if it is possible just try to avoid using it.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.