Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to compare two strings in a linq expression. Do I take advantage if I use `string.CompareOrdinal or is it the same?
list.Where(str1 => string.CompareOrdinal(str1, str2) == 0);
list.Where(str1 => str1 == str2);
According to benchmarks done by someone else, string.CompareOrdinal can be slightly faster than == when doing a lot of comparisons:
Most of the board remained green up through 10,000 comparisons and didn’t register any time.
At the 100,000 and 1,000,000 marks, things started to get a bit more interesting in terms of time differences.
String.CompareOrdinal was the constant superstar. What surprised me is for the case-insensitive comparisons, String.CompareOrdinal outperformed most other methods by a whole decimal place.
For case sensitive comparisons, most programmers can probably stick with the “==” operator.
-- The Curious Consultant: Fastest Way to Compare Strings in C# .Net
Note, though, that we are talking about a total difference of 3 milliseconds for 100,000 case-sensitive string comparisons, and that no measurable differences have been observed for 10,000 and 1,000,000 comparisons.
Thus, is very unlikely that this difference is relevant to your application (especially if you are using LINQ-to-objects), so the more readable == should be preferred.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
C# Why do arrays and collections have a difference between the names of the same attribute (Count and Length)?
It just causes headaches to people that are not familiar with this matter.
Length generally refers to a fixed size, whereas Count generally refers to content which could change. (I say generally because there are some exceptions to this, such as an IReadOnlyList which isn't going to change, but still has a Count since it is based upon a more generalized List interface.)
Besides #McGuireV10's answer part of the reason is historical. C# has it's roots in C, which use the "length" term when talking about arrays and strings. There was no compelling reason to not use "length".
Over the years, collections have been refined, genericized, and hold all kinds of different, countable objects, so "count" also makes sense.
I think another part of this is how we talk about our data structures. It is more natural to say, "what is the length of the array" than "what of the count of the array"; the former sounds natural, and the latter is ambiguous (did you mean count of items in the array or *the number of arrays".
Similarly when answering, "how many widgets are in the dictionary"? you are going to express your answer in terms of a count, not a length.
For something like a string, it's not wrong to think of it in terms of both count and length:
This string has (a count of) 40 characters
This string has a length of 40
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm returning a string from an API that has a length of 45 characters. There is one word that is unique for one condition that doesn't appear in the other condition.
I'm wondering if using string.contains() is faster performance-wise than comparing the whole string with string.equals() or string == "blah blah".
I don't know the inner workings of any of these methods, but logically, it seems like contains() should be faster because it can stop traversing the string after it finds the match. Is this accurate? Incidentally, the word I want to check is the first word in the string.
I agree with D Stanley (comment). You should use String.StartsWith()
That said, I also don't know the inner working of each method either, but I can see your logic. However "String.Contains()" may still load the entire string before processing it, in which case the performance difference would be very small.
As a final point, with a string length of only 45 characters, the performance difference should me extremely minute. I was shocked when I wrote a junky method to substitute characters and found that is processes ~10kb of text in a fraction of a blink of the eye. So unless you're doing some crazy handling else wise in your app, it shouldn't matter much.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Some coders will wrap each condition in its own parentheses, like this:
Style #1:
bool Test(string a, string b)
{
return ((a != null) && (b != null));
}
Style #2:
bool Test(string a, string b)
{
return a != null && b != null;
}
In C# the difference is purely stylistic (at least, I think so). The first expression evaluates first, and the second expression evaluates only if the first is true (otherwise it short-circuits because the entire expression is already confirmed false).
Someone mentioned that #1 above is an "old C style". What is its practical purpose? Is there any actual difference between the two, or is it some kind of safeguard against typos (like writing if (true == x) instead of if (x == true)).
I think this is just defensive coding so the writer of the code (and more importantly, future readers) do not have any doubts about the intent and function of the code.
A long time ago I spent many tedious evenings working through code with a colleague who refused to bracket terms due to his unfailing belief in his ability to remember precedence rules. Despite many examples to the contrary. Even when you know those rules yourself it is easier to read code where the intent is crystal clear, rather than double-checking every time.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
For instance, let's say you use fully-qualified namespaces instead of aliases or 'using' statements in an extremely large piece of software. Let's say you type in all kinds of nonsense that doesn't really need to be there, your arrays don't stop iterating when your goal is executed, etc, etc. Would these types of code inefficiencies affect the speed of execution of a piece of software today?
If by 'code bloat' you mean code that is less readable and unnecessarily complex, the main cost of 'code bloat' is longer development time, not slower code. That doesn't mean there's never a cost in terms of efficiency, but sometimes cleaner code is slower. So, I would say that code bloat doesn't necessarily mean the code is slower or faster, except that the unreadability can keep people from coding in performant ways because the hurdle is higher for understanding the code and optimizing for performance.
If by code bloat, you mean algorithmic efficiency, it probably depends on what you are doing. Something that has a performance curve of O(e^n) for large datasets is going to be slow, no matter how fast your processor is. That said, I usually base it on the size of n. If I know my dataset is going to be small (a hard-coded dropdown menu with 7 items), then I won't worry as much if I'm doing a linear search O(n) instead of a binary search in O(log(n)). But I usually tend towards doing it faster if possible.
Big-O-Notation in case I'm speaking greek: https://en.wikipedia.org/wiki/Big_O_notation
Off course number of characters, not even LOC, used in a program doesn't show complexity in general. So we cannot say about it's influence on the total throughput, at least in general terms.
However to be more accurate complexity of your program is really important not today even in the future. Please consider that our needs raise with our abilities. These days we are facing big data, and by this term we mean thousands of terabytes, but about 15 years ago this size of data was unbelievable.
Take a look at these two snippets:
//Block 2 - O(1)
int abcdef1;
int abcdef2;
//...
int abcdef100000;
//----------------
//Block 2 - O(n^2)
for (int i=0; i < n; i++)
for (int j=0; j < n; j++)
//do something
//----------------
it's clear that the number of characters is not a representative measure for complexity.
for more details visit :
Big-O for Eight Year Olds?
http://en.wikipedia.org/wiki/Big_O_notation (as mentioned before)
Do you use Big-O complexity evaluation in the 'real world'?
What is Big O notation? Do you use it?
What is the big deal about Big-O notation in computer science?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Can someone help me out with implementing this sequence of calculations in C#?
This problem essentially describes a CRC with a 24-bit polynomial.
You can solve the problem simply using shift and XOR operations and a 24-bit (or larger) variable; no bigint required.
Recommended introductory reading:
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
http://www.mathpages.com/home/kmath458.htm
http://www.ross.net/crc/download/crc_v3.txt
I took the opportunity to dabble with this. Interpreting the equations in the context of an implementation in software is tricky because there are many ways in which the polynomials can be mapped to data structures in memory - and, I assume, you'll want the solution you produce to seamlessly inter-operate with other implementations. In this context, it matters if your byte ordering is MSB or LSB first... it also matters if you align your bit-strings that aren't a multiple of 8 to the left or right. It is worth noting that the polynomials are denoted in ascending powers of X - whereas one might assume, because the leftmost bit in a byte has maximum index, that the leftmost bit should correspond to the maximum power of X - but that's not the convention in use.
Essentially, there are two very different approaches to calculating CRCs using generator polynomials. The first, and least efficient, is to use arbitrary precision arithmetic and modulo - as the posted extract suggests. A faster approach involves successive application of the polynomial and exclusive-or.
A implementation in Pascal can be found here: http://jetvision.de/sbs/adsb/crc.htm - translation to C# should prove trivial.
A more direct approach might involve encoding the message and the generator polynomial as System.Numerics.BigInteger objects (using C#/.Net 4.0) and calculate the parity bits exactly as the text above suggests - by finding the message modulo the polynomial - simply using the "%" operator on suitably encoded BigIntegers. The only challenge here is in converting your message and parity bits to/from a format suitable for your application.