cashBookForm.CashBook.AddNewTransaction performance

[neil.interactit]

Hi guys,

I haven't been able to find advice on this on the forum.

I have a batch receipt creation script that is bogging down when processing larger volumes and ultimately causing an out of memory exception. I have extensively analysed the plugin and progressively ruled out the SQL queries and various application logic calls, until narrowing it down to the cashBookForm.CashBook.AddNewTransaction call.

Code: Select all

        For Each eFTBatchDebtor As EFTBatchDebtor In eftBatchDebtors
            ReturnCode = cashBookForm.CashBook.AddNewTransaction(JiwaCashBook.CashBookTransactionCollection.TransactionTypes.Debtor, eFTBatchDebtor.RecID, Key)
            '[SNIP]
        Next


(other code in this loop all tested in the milli/microsecond range, so snipped)

A stopwatch on the above line, results in ...

perf.PNG (10.73 KiB) Viewed 2670 times

As you can see, the call takes progressively longer to return as the loop iterates (until it fails - out of memory - at 450th debtor).

Can you advise on required housekeeping, or an alternate approach, to fix this?

Cheers,
Neil.

[Mike.Sheen]

Hi guys,

I haven't been able to find advice on this on the forum.

I have a batch receipt creation script that is bogging down when processing larger volumes and ultimately causing an out of memory exception. I have extensively analysed the plugin and progressively ruled out the SQL queries and various application logic calls, until narrowing it down to the cashBookForm.CashBook.AddNewTransaction call.

Code: Select all

        For Each eFTBatchDebtor As EFTBatchDebtor In eftBatchDebtors
            ReturnCode = cashBookForm.CashBook.AddNewTransaction(JiwaCashBook.CashBookTransactionCollection.TransactionTypes.Debtor, eFTBatchDebtor.RecID, Key)
            '[SNIP]
        Next


(other code in this loop all tested in the milli/microsecond range, so snipped)

A stopwatch on the above line, results in ...

perf.PNG

As you can see, the call takes progressively longer to return as the loop iterates (until it fails - out of memory - at 450th debtor).

Can you advise on required housekeeping, or an alternate approach, to fix this?

Cheers,
Neil.

I don't think you can do anything other than break your batch into a few smaller ones. Batches involving 450 different debtors in one batch is a lot, not something we had in mind when building the cash book. I'm yet to find the time to replicate your issue, but I'm pretty sure I know where the problem is and it'll mean some significant changes to our strategies in the business logic to get any improvement.

If you can split into multiple batches, that would work.

[neil.interactit]

Thanks Mike,

I'll take this back to the client and see if that approach will meet their requirement.

Cheers,
Neil.

[Scott.Pearce]

Neil,

Which version of Jiwa? There are some patched jiwa.exe's available that are LARGEADDRESSAWARE that allow 32 bit processes to access a bit more memory. Have a look at this bug:

http://service.jiwa.com.au/browse/BUGS-4880

In particular, read comment 2 and follow the link it provides, and then read that.

We now always patch our jiwa.exe by default to be LARGEADDRESSAWARE for builds later than 7.0.157.0. Someday we will have to move to 64-bit only.