Re: [Dev-C++] differnece between system pause and cin.get()
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
|
From: Per W. <pw...@ia...> - 2003-02-18 07:43:27
|
On Tue, 18 Feb 2003, Ioannis Vranos wrote:
> -------Original Message-------
>
> From: Per Westermark
> Date: =D4=F1=DF=F4=E7, 18 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 2:16:24 =
=F0=EC
> To: Ioannis Vranos
> Cc: dev...@li...
> Subject: Re: [Dev-C++] differnece between system pause and cin.get()
>
> > =3D=3D> It depends on how many things are written inside get(). However=
the
> > member function call is usually faster than a regular function call. Bu=
t i
> > do not think you should be so space/time concerned. :)
>
> For just about any type of programming, you may ignore any speed
> difference between member call and regular function call. For a new
> normal PC, we are talking nano-seconds. A member function call is normall=
y
> just a teeny bit slower, since it is a regular call with the extra
> requirement that it must send a 'this' pointer in registers or on the
> stack. If the member function is virtual, the member call must also
> perform the call indirect, by locating the call address in the VMT
> for the object. The only time a member call is as fast as a regular
> function call is if the member function is declared static - but then it
> is a regular function declared in the namespace of the class.
>
> -------------------------------------------------------------------------=
----
> ------------
> =3D=3D> We are getting lost in the details here, but for non-virtual memb=
er
> functions passing *this does not imply any additional time cost in
> comparison to regular functions. Also i do not think passing *this to
> anything is required. Member functions do not have a regular address. The=
y
> are usually called as an offset in an array. It is something like
For register calling convention, the this pointer may be sent for free
from one member of the class to another member of the class, since the
register will already be initialized with this. For stack calling
convention, it HAS to take extra time, since it's an extra 32-bit put push
on the stack. Also, weith register calling, the first call HAVE to take
extra time, since the compiler must load the address of the object before
making the call.
The only time the compiler can avoid passing the this ptr at a method
call, is if the destination method is non-virtual and the compiler
generates the code inline. Even if it knows that a specific method never
touches any part of the object, the compiler may only ignore the this ptr
if it knows that ALL uses of the method will always use same calling
convention. If some modules just sees the declaration of the method wile
compile modules may see the full implementation, the compiler must be
consequent and assume that the method needs the this ptr. Static-declared
methods are the only way to inform the compiler that a method does not
have a this ptr. But then a static method is a regular function declared
in the namespace of the class.
Member functions always have a regular address. Your description of call
through an offset in an array is the special case of a call to a virtual
method. However, the constructor for the same class may still call
directly without going to the VMT (Virtual Method Table). A call through
the VMT is slower, since the compiler first have to load the VMT table
address as an offset from the this pointer, and then do the call from an
offset into the table.
If you don't believe me, just ask the compiler to emit assembler output
and have a peek.
>
> array[4](whatever)
>
>
> A regular friend function call for example would be implemented as someth=
ing
> like:
>
> something(this, whatever). It's tough to say which is faster. So lets
> consider them as of equal time cost and be in peace. :P
>
> However statistically speaking member functions tend to be small and inli=
ned
> while regular functions manipulating objects not. But this can be disput=
ed
> too. As i said, this shouldn't be taken under any consideration, that is =
the
> time cost difference between cin.get() and system("pause"). Although syst=
em
> has a function call time cost+a program invocation time cost+command.com/=
cmd
> exe invocation time cost.
> -------------------------------------------------------------------------=
----
> ----------------
The information that may be seen from a couple of analyzes of different
compilers - several peopple have done it is:
A cpp+ compiler normally generantes more efficient code for a member call
with implicit this pointer, than the corresponding C code with an explicit
THIS ptr, i.e.
obj->hello(a,b,c);
is normally faster than
hello(&obj,a,b,c);
and a C++ call to a virtual method normally generates better code than a C
call through a pointer access, i.e.
obj->my_virtual_call(a,b,c);
is normally faster than
obj->vmt[3]->my_virtual_call(&obj,a,b,c);
But this is just that since a C++ compiler have somany this references and
VMT-indirect calls, the compiler writers have made sure that these cases
should generate good code, my making sure that the this ptr have a high
priority while assigning register variables etc. It still doesn't change
the fact that for stack parameter passing, the this ptr is extra work, and
a virtual method is always extra work compared to a non-virtual method or
compared to a regular function call.
Bottom line: As I said on my original mail, member calls are slower than
regular calls, but these extra nanoseconds might be ignored for just about
all programs out there, since the majority of the runtime is in other
parts of the program.
>
>
>
> What is important in this case is that system() is special. It is a
> request to start a new program 'PAUSE' and wait for that program to end,
> i.e. wait until you press a character.
>
> This is not the slightest problem for testing a debug-version of a
> program. However, in real production code, some care should be taken abou=
t
> the use of system() calls, because of the very large amount of work the o=
s
> has to do to perform the call. One call to system() might sound nice, but
> probably represents 100-10000 calls or more depending on what type of
> command that are put as argument. The OS has to start a new proces, with
> new stack... and might in some cases consume more memory and/or cpu
> time for the system() call than for the rest of the application.
>
> =3D=3D> Yes.
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
|