-2

Is strcmp slower than strncmp as one can give pre-calculated string length to it, but strcmp does not receive such information ?

I am writing an interpreter. I am aware that these functions are both optimized. I wonder what will be the better approach (in terms of performance), as I will do scan anyway and I will know offset positions hence lengths.

mrflash818
  • 930
  • 13
  • 24
Imobilis
  • 1,475
  • 8
  • 29
  • -2 downvotes for 1 second I see where is this going. – Imobilis Aug 25 '16 at 20:52
  • 2
    not really, you have to scan anyway. Remember, its _at most_, not exactly. – Sourav Ghosh Aug 25 '16 at 20:52
  • I meant around the buffer so that I can compare substrings. If I iterate through all characters I can invent a way to obtain string length without doing additional loop as if strlen was involved. – Imobilis Aug 25 '16 at 20:54
  • 2
    Those downvotes must be for "lack of research" (per its tooltip). A cursory search on common implementations show no use of lengths. Both simply test for a `null` character. – Jongware Aug 25 '16 at 20:55
  • If it is a substring, it will not have null character unless I also perform string copy. – Imobilis Aug 25 '16 at 21:01
  • 2
    For an actual call, it depends on how the limit compares to the length of the string. If you have a 1,000-byte string, but specify `limit = 10`, it will be faster. But if you specify `limit = 900`, it will probably be slower. – Barmar Aug 25 '16 at 21:01
  • 1
    @Malina `strncmp()` still has to check for the null character, because it has to stop copying there even if `limit` is larger. – Barmar Aug 25 '16 at 21:02
  • Well I firstly searched the internet for similar question. Then I asked. If that's the definition for a "lack of research" – Imobilis Aug 25 '16 at 21:02
  • `strncmp()` doesn't know that your string doesn't have a null character, it has to check. – Barmar Aug 25 '16 at 21:03
  • @Barmar it has given length but also checks for null for safety ? This can be optimized in the cost of safety. – Imobilis Aug 25 '16 at 21:03
  • 2
    The argument to `strncmp()` is not a given length, it's a **maximum** length. – Barmar Aug 25 '16 at 21:05
  • True, okay then memcmp doesn't check for null, it is the better approach from these two I assume – Imobilis Aug 25 '16 at 21:07
  • @lurker, it scans while `*a == *b` and there is no need to reach the end of string, isn't it? – David Ranieri Aug 25 '16 at 22:02
  • Get it working first, and working safely, before worrying about optimizing the code. If you're just starting such a big project, microoptimizations like strcmp vs. strncmp should be the last thing on your mind. – Andy Lester Aug 25 '16 at 22:32
  • 1
    Is a "bike better than an umbrella" - When it rains, a bike has little use. But it is a bad idea to ride it. You compare apples and oranges. – too honest for this site Aug 25 '16 at 23:01

3 Answers3

3

They do different things, so comparing them directly does not make sense. strncmp compares the first n (or fewer, if the string ends sooner) characters of a string. strcmp compares whole strings. If n is sufficiently large that strncmp will compare the whole strings (so that the behavior becomes effectively the same as strcmp) then strncmp is likely to be moderately slower because it also has to keep track of a counter, but the difference might or might not be measurable or even present in a given implementation. For example an implementation of strcmp could just pass SIZE_MAX as the value for n to strncmp.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • There are some CPUs which have special instructions for this. They actually can even be faster. (One prominent historical example would be the 68010, see `DBcc` and loop-cache). AFAIK x86 can do similar. But even without this, superscalar CPUs can very well process both loops equally fast. – too honest for this site Aug 26 '16 at 00:10
2

There is only one way to know: benchmark it. Speculation is of no use.

Be sure to do that with a sufficiently large number of strings and in representative conditions (statistical distribution of string lengths and statistical distribution of matching prefix lengths).

My bet is that there will be no significant difference.

0

You state that performance is a problem, so let's concentrate on that.

Implementations of library functions vary from compiler vendor to compiler vendor, and also across versions of the same compiler or development environment. Thus, Yves Daoust is correct when he says "there is only one way to know: benchmark it."

I would go further and suggest that if you haven't profiled your code, you start by doing that. The bottlenecks are all too often in surprising places you'd not expect.

It may do some good, however, to compare the implementations of strcmp() and strncmp() if you have the source code.

I once found myself in very nearly the same situation you are in. (Writing a front end information display that used multiple character based terminal backends to do its job. It required repeated near-real-time parsing of several text buffers.) The Borland compiler we were using at the time had an inefficient strncmp(). Since the processor had a length-limited instruction for comparing character buffers, I wrote a specialized variant of strncmp using assembler. "Before and after" benchmarks and profiling revealed we'd removed the primary bottleneck.

Several years later when folks went back to improve and modernize that system, the compiler and its library had changed (and the processors upgraded): there was no longer any real need for the (now obsolete) special version. New benchmarks also revealed that the bottlenecks had moved due to changing compilers, necessitating different optimizations.

Forbin
  • 123
  • 8