Which is faster?

[Old Wolf]

I am writing a routine to send Credit Card transactions to the
authorizer. Obviously the biggest speed issue will be the
network speed, however, I was just trying to cut down the amount
of time I spend preparing the transactions. It is not just one
field that needs to be set to spaces. The authorizer sent me the
record layout for the authorization request. This layout is a
catch all that contains a number of fields that I won't need.
For example, there is approximately 100 char's dedicated to
shipping address that need to be set to spaces. This is being
developed for a convenience store so shipping address is not
really necessary. There are also fields for dealing with
reversals, PIN data, and various card specific fields that will
only be used in certain situations.

Your primary concern is application financial integrity.
You should write the simplest, clearest, most portable,
most maintainable code possible. For example:
char x[10] = " ";
is bad because you can't see at a glance whether it is correct
or not, and it doesn't hold up well to the dimensions of x changing.
This would be even worse if x were a member of a struct, and the
" " were part of a struct initialization.
I also suggest you learn basic things like the fact that string
literals are 0-terminated, and strcpy() works with 0-terminated strings.

It won't be a good look if your customer comes back to you saying
"Why did my card get charged twice", and you say "Dunno but the
terminal only took 14.999 seconds instead of 15 seconds to process
the transaction"

 

[Villy Kruse]

I need to fill a number of character fields with spaces or zero's
depending on the field. Which method is faster.

char var[10] = " ";
var[9] = '\0';

I would think this one is the fastest, will probably be translated by the
compiler by a 'multiple store' instruction.

or

char var[10];
sprintf( var, " " );

Involves a function call, pushing to the stack, changing program counter,
going back and forth.

or

char var[10];
strcpy( var, " " );
var[9] = '\0';

same as above

Perhaps, perhaps not. Compilers may recognize this as a known function and
inline it as a series of moves just like the first example, especialy when
the size of the source string is known at compile time. The second example
may also be recognized as a special case of sprintf and substitute strcpy
and inline it.

Compiler optimizations may make all assumptions of which is faster
invalid, so if someone realy wan't to know for a particular compiler
on a particular computer model using a particular optimization option,
you need to benchmark it.


Villy

 

[Alex]

[snip]

typedef struct rcd {
/* fields */
} rcd;

rcd blankrcd = { /* initializer statements */

Possibly 'static' at file scope, or 'static' within initandsend() - ie, use
the smallest scope sensible. In either case, 'const' would make sense.

 

[Christian Bau]

I am writing a routine to send Credit Card transactions to the
authorizer.

If you are doing that, and you are asking on comp.lang.c for help, then
I am slightly worried.

 

[Justin Robbs]

message

If you are doing that, and you are asking on comp.lang.c for help, then
I am slightly worried.

Why? I am a fairly competent C programmer. I have always been
able to get the computer to do what I want it to do. I just
thought I would take some extra time to ensure that I am going
about this in the best way. Since I have taught myself, I figure
if I am not sure of something I should ask for advice. My
teaching has been by necessity so while I actually know some
reasonably advanced stuff, there are some areas where my skills
need refining. I have never had to worry much about performance,
but I just wanted to ensure I wasn't using a sledge hammer on a
push pin.

I have the tools, time and facilities to test this quite
thoroughly before it goes into production. Even the most
experienced guru's (not that I necessarily am in that group)
encounter problems they need help with. That's partly why usenet
was created. The wisest people in the world are those who know
when they need help.

Besides, it is not like the process is overly difficult.
Customer swipes card, program reads card, send card and
transaction data to authorizer, and wait for response.
Obviously, I will be testing very thoroughly due to the sensitive
nature of what I am doing, but that doesn't mean the process is
that difficult.

 

[Arthur J. O'Dwyer]

If you are doing that, and you are asking on comp.lang.c for
help, then I am slightly worried.

Why? I am a fairly competent C programmer. I have always been
able to get the computer to do what I want it to do. [...]
Besides, it is not like the process is overly difficult.
Customer swipes card, program reads card, send card and
transaction data to authorizer, and wait for response.
Obviously, I will be testing very thoroughly due to the sensitive
nature of what I am doing, but that doesn't mean the process is
that difficult.

I do believe Christian's point is that if you cannot by yourself
figure out things like variable initialization in the relatively
straightforward C programming language, then you probably oughtn't
to be messing around with real people's sensitive data over publicly-
eavesdroppable telephone lines.
The C language can be remarkably unforgiving when it comes to
things like debugging. Watch out for buffer overflows and un- or mis-
initialized variables.
Even besides the pitfalls of writing a complex program in C,
you'll have to deal with the pitfalls of real cryptography. This
is a non-trivial field, even if you are planning to use a pre-rolled
and open-source crypto library for the dirty stuff.
There is already a whole lot of code out there in the world that
tries to do serious stuff and fails miserably because the programmers
involved did not understand what they were getting into. (Cf. Microsoft,
Diebold.) Please, please, *please* make sure you're not going to be
contributing to that supply!

HTH,
-Arthur