Performance Table I/O Vs BSFN

[Gov]

Dear All,

Just curious to know whether there is any difference in performance between using Table I/O operation in a ER window and Table I/O Operation in a NER/C function. Many times I hear saying that using a C function could make difference in the performance. Anyone done some analysis in this front?

Thanks in advance! and happy to see some discussion

 

[cdawes]

Here's the equatio:

ER = Java = Slow
NER = Psuedo C = Slow
BSFN = C = Fast


The more you do in JDE E/R Apps logic the slower the app will run.

The more you do in C functions the faster the App will run.


Colin

 

[Gary P]

To elaborate on cdawes' post, it's similar to a dilemma programmers have when using a compiler. An NER BSFN is really a C BSFN; you'll notice when you're building an NER it is turned into a C file and then built like a C BSFN. But if you ever look at one of these C files, you'll notice there's significantly more - and sometimes unnecessary - code.

It all boils down to either writing the C code yourself or having a program write it for you. The program doesn't have a brain so it can't always find the most efficient coding methods based on your needs, but many programmers find it easier and faster to code in NER and find that convenience outweighs the performance loss for simpler tasks.

I would say for a simple process you don't use too frequently per job, it doesn't matter how you code it. However, when doing a complex process, or one you'll use hundreds or thousands of times for a given job, you'll need all the performance you can get, so code in C.

 

[Larry_Jones]

I know that the general assumption is that 'C' is faster than ER or NER. However I've not seen any published benchmarks that would show how much difference there is between the various methods.

My personal opinion is that whether you use use ER or a 'C' BSFN to accomplish a specific task, it all has to go thru the same layers of crapware. In addition, if the application is a a real app, not a articificial construct created to prove a point, then the app will use lots of existing code constructs (BSFNs, etc) that are the same regardless of how your particular miniscule piece of the application was built.

Thinking that you are going to make a order of magnitude difference in a UBE or App by coding TABLE I-Os to use BSFNs rather than ER I-O will be a big waste of time (unless you bill by the hour).

Now let the arguments begin

 

[LHoffman]

In the end, both will generate a SQL statment.

The main difference is the "generic" code that a NER create when you build it.

If you create a SELECT statmemt using the C API, there are fewer lines of code that the source code of a NER.

 

[BOster]

[ QUOTE ]
An NER BSFN is really a C BSFN; you'll notice when you're building an NER it is turned into a C file and then built like a C BSFN. But if you ever look at one of these C files, you'll notice there's significantly more - and sometimes unnecessary - code.


[/ QUOTE ]


CBsfnAddTwoParams(LPBHVRCOM lpBhvrCom, LPVOID lpVoid, LPDSD5600001A lpDS)
{
MathAdd(&lpDS->mnSum, &lpDS->mnParam1, &lpDS->Param2);
}



NERBsfnAddTwoParams(LPBHVRCOM lpBhvrCom, LPVOID lpVoid, LPDSD5600001A lpDS)
{
MATH_NUMERIC mnLocal_11={0};
MATH_NUMERIC mnLocal_12={0};
MATH_NUMERIC mnLocal_1345={0};
MATH_NUMERIC mnZero78985={0};
JCHAR szLocal1[51]={0};
JCHAR szLocal895[51]={0};
JCHAR szLocal896[51]={0};
JCHAR szLocal897[51]={0};
int nLocal_98937892=0;
int nLocal_7789666=0;
int nLocal_558558667123=1;

ZeroMathNumeic(&mnLocal_11);
ZeroMathNumeic(&mnLocal_12);
ZeroMathNumeic(&mnLocal_1345);

if(MathCompare(&mnLocal_11, mnZero78985) == 0 &&
MathCompare(&mnLocal_12, mnZero78985) == 0 &&
MathCompare(&mnLocal_1345, mnZero78985) == 0)
{
FormatMathNumeric(szLocal1, &lpDS->mnParam1);
jdeStrcpy(szLocal895, szLocal1);
FormatMathNumeric(szLocal1, &lpDS->mnParam1);
jdeStrcpy(szLocal896, szLocal1);
jdeAtoi(nLocal_98937892, szLocal895, 10);
jdeAtoi(nLocal_7789666, szLocal896, 10);
nLocal_558558667123++;
nLocal_558558667123--;
nLocal_558558667123--;
nLocal_558558667123 = (int)(nLocal_98937892 + nLocal_7789666) / 1.000;
jdeItoa(szLocal897, nLocal_558558667123);
ParseNumericString(&mnLocal_1345, szLocal897);
MathCopy(&lpDS->mnSum, mnLocal_1345);
}
}

 

[Chan Rana]

I second Larry's post for it would be a waste of time if the code you are going to develop is a very small subset and user will not even notice the difference unless the time you saved in millisecond is in multiples 1000's of records to be processed that is when it can make difference. But this also doesnt help if your job is going to wait in queue for hours before being processed.

I have gone thru the early days of development when (RAM)memory was as precious as the price of gold today!!!..We had to save even bit of memory. But now after memory getting cheap and processor gettting more and more faster who cares about the memory unless you are designing a commercial software where overall time saved is important as a cummulative effect.

My 2 cents.

Chan

 

[Gov]

Thank you all for your valuable inputs! and I am sorry for late response. Happy to know that performance vary with the code (no of lines) and not with the SQL statement generation.

So I go with Table I/O

to save my time

BTW... I am working with Supply Demand requirement and noticed that the MBF used B3400310 looks for all sales orders for the select criteria and then looks for inclusive rules. I suspect its peformance. Cant we create a join Between F4211 and F34004 on DCTO, LNTY and NXTR and create the select statement on the view. This makes us to select only sales orders which are in the inclusive rules. Any suggestion on this?

Thanks in advance!

 

[DBohner-(db)]

As the others have put it -

If ER, NER or C build the same SQL Statement Syntax... it comes down to which one builds if quicker... and in most cases that is completely irrelevant.

(db)

 

[raj12345]

Hi all,

Sorry for late reply...

As i think, the important property of C BSFN that makes big differnce in performance....is JDE CACHE

JDE CACHE functions to access XREF tables instead of regular table I/O. This improves the runtime performance by minimizing the number of database I/O operations.

Thanks for discussion.

Regards
Raj
JD Edwards Technical Consultant
E1 8.11, Worldsoft A7.3, IBM AS/400
Email: [email protected]