11.7.4..just wondering if this is expected. I know there is a performance hit with ABL classes but to this extent?
If we call the following 1000 times it will take 7348ms!!
(NEW Osprey.PointOfSale.PosTransaction.UpdateMediaTotal (oTransactionTotals)):PerformUpdate (DATASET dsPosTransaction BY-REFERENCE,
iMediaType,
iRecNum,
dTenderAmount,
NO,
dECCAmount,
cCardType
).
If we do the same with a .p it takes only 166ms.
RUN Osprey\PointOfSale\PosTransaction\UpdateMediaTotal2.p (oTransactionTotals,
DATASET dsPosTransaction BY-REFERENCE,
iMediaType,
iRecNum,
dTenderAmount,
NO,
dECCAmount,
cCardType).
If we create an instance of the class only once and call the PerformUpdate METHOD 1000 times it takes 3697ms.
oMediaTotal:PerformUpdate (DATASET dsPosTransaction BY-REFERENCE,
iMediaType,
iRecNum,
dTenderAmount,
NO,
dECCAmount,
cCardType
).
au contraire what I expected...
|
For this small test we were using the following for startup.
-debugalert -inp 32000 -tok 4000 -rereadnolock -s 1024 -mmax 65534 -nb 255 -D 100000 -zn -errorstack -reusableObjects 100000 -q
As far as the class all it references is an include file that has the PDS definition. This PDS is setup as REFERENCE-ONLY.
Okay, I guess it helps to compare apples to apples.
The UpdateMediaTotal2.p we created to compare performance had no logging as it was all removed for this test. The classes still had some logging enabled which is what was slowing down the test.
After removing the logging the results are;
Calling .p 1000 times - between 80-100ms
Creating instance of class and calling METHOD 1000 times - between 20-25ms which is faster than calling the .p.
NEWING class and calling METHOD at same time - between 100-120ms
For performance tests I also like to add the -rr parameter which disables the compiler.
That way you can be sure no on the fly compilation is influencing the results.
> Creating instance of class and calling METHOD 1000 times - between 20-25ms which is faster than calling the .p.
That should be compared to persistently running a .p and calling an internal procedure in that .p
> That should be compared to persistently running a .p and calling an internal procedure in that .p
Absolutely...thanks.