LotusScript agent performance

HCL Domino Domino Forum
1

Hi

I have a problem with LotusScript agent running on R9.0.1FP7 on Windows and AIX.
The problem is in low performance of arithmetics written in LS. Actual function (see below) tries to find particular sum between array members. To do so, it tests all combinations of array members (which are Long type) and compares its combined total with target.
When I run this agent on server (either way - from console, by schedule or from web request), it works. But it takes too much time to finish. Profiling shows that most of time is spend in this my function (tens of minutes).
And what is sad here: there no CPU spikes in that time, all cores almost idling.

How can I tune server to yield more CPU time on LS computations ?

Dim gArrValues() As Long
Function findRandomSum( curSum As Long, targetSum As Long, i%, endd%, found$)
’ combines elements of garrValues to find targetSum
If i > Endd Then
Exit Function
End If

findRandomSum = False
Dim localsum As Long

localsum = curSum + garrValues(i)
If localsum = targetSum Then
findRandomSum = True
End If
Call findRandomSum( curSum+garrValues(i) , targetSum , i+1, endd%, found+“+”+CStr(i))
Call findRandomSum( curSum+0 , targetSum ,i+1, endd%, found)
End Function

Thanks in advance,
Vlad

2

Subject: Mike, thanks for thoughts

Yes, it is searching of combinations and it is pn, so it takes huge time to finish and yes, endd% is artificial limit here.

Main problem for me here is that CPU almost idling while while doing this long computations (all cores!). And I see only way for make it better: rewrite in Java using NotesThread to do multithreading.

But if there is a way to fine-tune server to spend more CPU time on LS engine, it would be better. I remember in R4 (or R5?) there were some settings in server document for AMgr, but they are useless in R9 world

3

Subject: Hm. Well, it’s gonna calculated out of control at the count goes up.

Is it that you’re searching for combinations that meet a target? It sounds like an pn problem, so it’d have to be a pretty small number of combinations.

The problem itself seems to spin out of control at a factorial rate.Because it’s pn,

  • you could only make stabs at keeping it from exploding in sheer number of calculations.
  • Or, you can limit the problem to some manageable list.
  • Or, you can try to redefine the problem.
    Only thing I can try is to improve its performance. So for small Endd …

  1. I see a “The Price is Right” situation. That is assuming your garrValues are all positive, though. If they are, then you can stop checking that line of combinations once curSum > targetSum. However, that’ll only cut your calculations by division; finding all combinations is still exploding at a factorial rate.

  2. If this is a “Price is Right” situation and you don’t have to be exhaustive in all the combinations, you could try sorting the garrValues, descending. That way the largest counts get excluded first, leaving the small values to be hashed out. But this is no help if you need to be exhaustive.

  3. It’s likely all the combinations aren’t needed, either. I’d propose stopping when you find a smallish number of combinations that satisfy. That could mean adding features so the user can highlight certain entries that are absolutely necessary in the combinations. That feature alone will reduce the whole set of calculations, too: making it smaller, and less of a factor.