[D#83056] SalCompileAndEvaluate performance issues

forum.gupta.bugreport (2005-2010)
Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 3390
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

[D#83056] SalCompileAndEvaluate performance issues

Post by Dave Rabelink » 28 Apr 2005, 20:45

 Posted by:  Dave Rabelink 

Log-A-Bug has reviewed the issue listed below and determined that this
is a defect. The defect number is 83056.

For further information watch for the fix in the Fixes.Wri file in
future PTF’s or Releases.

When using SalCompileAndEvaluate in Dynalibs, the performance of this
command depends on the build of the Dynalib.

Thank you,

Log-A-Bug

A Service of Gupta Technologies

**************************************************************************

Defect report

I have discovered a strange effect when using SalCompileAndEvaluate
on TD 3.1. I have tested it on PTF1 and PTF3 and on both versions the
defect can be seen. I dont know about other PTF's !

Description :
When using SalCompileAndEvaluate in Dynalibs, the performance of this
command depends on the build of the Dynalib. Normally when evaluating
variables with this Sal statement the performance should be very fast.

But often when the dynalib is edited and build to a new APD file
the statement could get slow, even so slow the statement seems not to
return. During the SalCompileAndEvaluate
execution, the Workstation gets to 100% CPU usage and the memory is
consumed rapidly until the Workstation does not respond anymore and a
hard reboot is needed.

This issue is seen on dynalibs. If it is present on executables also
is not tested, but this could be the case.

The problem occurs on Windows XP (SP1 and SP2) and on Windows NT
(build6a). So there seems no OS compatibility issue here. Also having
local admin rights or less does not matter !

I have searched long for the reason why some functions within our
dynalibs take so long in TD 3.1.
The same functionality under TD 1.5.1 (PTF6) is very fast and when i
ported the applications to TD3.1
our customers complained about huge performance loss and even locks !

After a while i found that just rebuilding the slow or faulty APD
solves the problem. No code is changed what so ever, just open the
source in TD, and rebuild the APD file.
But often also this does not resolve the issue. Sometimes the
performance is less slow and on other
rebuilds the APD seems to lock and never finish it's functionality.

And then i found the point in the code where the problem lies :
SalCompileAndEvaluate !
This function is used in our dynalibs to evaluate variables which are
declared within those dynalibs.
To test how long this statement is doing for 1 evaluation i placed
SalTrace functions before and after
the statement. When the APD is OK, the time it takes is very fast. The
Trace log shows only seconds, but
there it shows 1 statement takes less than 1 second.

When i edit the APD (just including libraries, shuffle code, adding
dummy classes and variables) and build
the APD to a new file, often i can see huge time differences for the
SalCompileAndEvaluate statement.
At one point i got 19 seconds to complete 1 evaluation. The evaluation
is correct by the way, the expected value is returned.

So there is a link between compiled dynalibs and the speeds this
statement takes.
It is not sound that it can take 19 seconds or more for 1 evaluation
when less than 1 second is expected !
So there must be something wrong.

I have a theory what is happening : SalCompileAndEvaluate evaluates at
runtime. So it tries to
find the given variable name in its context and evaluates it. I dont
know how this is technically done
within the runtime environment of TD, but i believe TD uses some kind
of symbol table. Seems this table
can be corrupted on some builds, so the SalCompileAndEvaluate
statement kan not find the variable or
it searches a corrupt table which takes too long.

At this point we have troubles getting our APD's working. There is no
way to make a correct APD when
using a predetermined procedure for compiling (first refresh libs, F8
to build and then build to file
for instance). We have to try and error to see if the compilation
resulted in a correct APD.
This issue has decreased or productivity alot !!

So i tried to reproduce the issue with a simple example and i
succeeded to get a situation that resembles our findings.

DynalibServer_OK.apd EXEC TIME : ± 1 secs
DynalibServer_SLOW.apd EXEC TIME : ± 3 secs
DynalibServer_VERY_SLOW.apd EXEC TIME : ± 83 secs

The time it takes to evaluate all values is shows above for the 3
dynalibs.

When requested i will send the sources as ZIP by email.

Return to “gupta.bugreport”

Who is online

Users browsing this forum: [Ccbot] and 0 guests