I would suggest you submit this as a bug to IBM.

While some difference in performance is understandable, a 2X difference is not acceptable.

Report it and see what IBM have to say.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 16, 2015, at 11:00 AM, Jevgeni Astanovski <jevgeniast@xxxxxxxxx> wrote:

No chance, Charles.
All three are compiled in 2 phases and all three use ACTGRP(*CALLER).


On Mon, Feb 16, 2015 at 5:10 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:
Any chance your C++ programs are using ACTGRP(*NEW) and the C ones are not?

Charles

On Mon, Feb 16, 2015 at 9:56 AM, Jevgeni Astanovski <jevgeniast@xxxxxxxxx>
wrote:

Hi all.
Does anyone have any idea why C++ program is significantly slower than
C program?

Explain the situation.
I have a number of API-s that are called via RPC, access some tables,
make some calculations and return some structures to the caller.
They've all been written on ILE/C.
Recently I started to experiment with porting them to ILE/C++. There
was a number of reasons why it would be nice.
After I rewrote the first one, I started to measure performance. This
is an issue for me as some of them are called hundreds of thousands
times per day.
Found out that it is approximately 2 times slower than C version.
Shared a code to colleges - no one found anything suspicious. However
one guy came out with a "brilliant" idea - he advised me to try to
recompile my C program with CPP compiler and see the performance.
Guess what? C program compiled with CPP compiler was the same 2 times
slower than C program compiled with C compiler....

And the only modifications that I did for compiling C with CPP compiler
was:
1. Substituted "#pragma mapinc" table structue definitions with those
generated by GENCSRC;
2. Changed char and unsigned char in a couple of places as C++ is more
strict;
3. Made a substitution for "NNNND" constants (like 100D for example)
as C++ does not support that.

What I saw is that time increase looks like it has a proportional nature.
I tested API in 3 cases (number of tests is over 100): simple request,
medium request; complicated request and the timing is:
Simple C: 1ms; Simple C++ : 2ms
Medium C: 3ms; Simple C++ : 7ms
Long C: 25ms; Long C++: 60ms.

The difference is in number of records read from table and a number of
calculations.
That is a simple one retrieves less that 10 records; medium - more
than 10 and long - more than 100. Program makes a lot of calculations
with packed decimal.

Any idea why it is like that and is there anything that can be done about
it?

Thanks in advance,

Jevgeni.
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.


--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact [javascript protected email address].