Which one is faster?
Regex.Replace(textBox1.Text, @"\r\n", "<br>", RegexOptions.IgnoreCase);
vs
textBox1.Text.Replace("\r\n","<br>");
-
Follow
Oops, something didn't work.
Sign In to be begin to follow this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.Getting "follow" information
Start following this thread
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.Removing your "follow"
Setting up your "follow"
Did you know you can
sign up for email notifications?
-
turrican
Nothing is forever. - Art Bell
-
W3bbo
Work hard; increase production; prevent accidents, and be happy.
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. -
turrican
Nothing is forever. - Art Bell
Thanks! I keep forgetting it's <br />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. -
Matthew van Eerde
AKA Maurits
> verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.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.
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.
-
W3bbo
Work hard; increase production; prevent accidents, and be happy.
Oh, I forgot that the Regex in .NET also recognises C-style escapes for newlines and carriage returns.Matthew van Eerde said:
> verbatim strings @"" don't support escape characters also they're not recognised by the regex engine.W3bbo said:*snip*
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.
-
TommyCarlier
Widen your gaze
<br/> is only necessary in XHTML. Regular HTML does not need the backslash.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. -
stevo_
Human after all
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.TommyCarlier said:
<br/> is only necessary in XHTML. Regular HTML does not need the backslash.W3bbo said:*snip*
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. -
W3bbo
Work hard; increase production; prevent accidents, and be happy.
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).TommyCarlier said:
<br/> is only necessary in XHTML. Regular HTML does not need the backslash.W3bbo said:*snip*
-
Yggdrasil
Pour me a cab, 'cause I can't drink no more.
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.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. -
evildictaitor
I'll live forever, or die trying!
On the other hand string.Replace(string, string) is semantically easier to understand than the Regex equivilent.JPBuckeye said:
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.Yggdrasil said:*snip*
Consequently it is definitely a good idea to go with the string replacement unless you have good reason not to.
-
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.Programous said:Given two ways of doing something, regex is almost always slower.
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.