Corno
Corno

Reputation: 5396

performance of pointer comparison vs string comparison strcmp

I have the choice to do either a pointer comparison or a strcmp. I know that the string is never longer than 8 characters and I'm targeting a 64 bit platform. will they perform equally well or will one of them be a better choice? I can imagine that this might differ between platforms and compilers, if so, I'd like to know the details about the platform/compiler specifics.

gr,

Coen

Upvotes: 1

Views: 1989

Answers (3)

Two strings (even short ones of 8 char) can be equal but at different addresses, so comparing pointers is not the same as using strcmp.

But your application might do hash-consing or string-interning, that is have a canonical string (e.g. like Glib quarks)

And you should not bother that much about performance, unless you measure it. Notice that some compilers (with high-enough optimization levels) are able to optimize quite well strcmp calls.

addenda

If your strings are not real arbitrary strings but 8 bytes, you might declare them with a union (which the compiler will suitably align and perhaps optimize).

typedef union { 
    char eightbytes[8];
    int64_t sixtyfourbits;
} mytype_t;

then you might initialize

mytype_t foo = {.eightbytes="Foo"};

If you are sure that the strings are 0 byte padded (like the above initialization do; but if you heap allocate them, you need to zero them before filling e.g. with strncpy(p->eightbytes, somestring, 8) etc...), you could compare foo.sixtyfourbits == foo2.sixtyfourbits ... But I find such code exceedingly bad taste. If you really want to code this way, add a lot of explanatory comments. I believe that coding this way makes your code unreadable and unmaintainable, for a probably very tiny performance benefit.

Upvotes: 0

Jim Balter
Jim Balter

Reputation: 16426

A pointer comparison will almost certainly be faster, as it is a single comparison of two pointers (possibly loading one or both into registers), whereas strcmp, even if inlined and the first bytes differ (best case) will require dereferencing both pointers. If strcmp isn't inlined then there's a function call and return, and if the first bytes don't differ (and aren't both NUL) then there are multiple dereferences.

For more insight into this, I suggest looking at the assembler output of your program using both methods.

Note: I'm assuming that your claim "I have the choice to do either a pointer comparison or a strcmp" is correct, which will only be the case if your strings are all known to have unique content.

Upvotes: 5

Devolus
Devolus

Reputation: 22094

The first question should be: Is this comparison the critical path in my executable? If not, the performance question might be irrelevant, because the impact may be so minor that it doesn't matter.

Comparing the pointers is only a subset of strcmp, because you don't know if the stringvalue is the same if the happen to be in different memory locations. You may have to consider that, in your design.

A pointer comparison is certainly faster. However, if you have a guaruanteed string length of 8 bytes, you may compare the strings without strcmp and use a datatype that has an 8 byte length and can be compared directly. This way you have basically a similar speed as a pointer comparison AND also compare the strings as well. But of course, this would only be reliable if you make sure that all strings are 8 bytes, and if they are shorter, you fill the remainder with zeroes.

Upvotes: 1

Related Questions