I am doing some performance testing comparing different implementation alternatives. One of these is a dynamic TT alternative which I curbed from AETF and another is a static implementation which I wrote. They are not strictly equivalent in several respects including the inheritance hierarchy and functional differences which shouldn't impact the tests I am running. While this is something of a moving target because I keep fiddling with the code, in some tests it appears that the dynamic code is actually performing better than the static code. This makes no sense to me, but before I try to trace it down, I thought I would ask. Have you ever seen a dynamic implementation of a function outperform an equivalent static implementation? This makes no sense to me, but if true, then I am going to have to consider me own dynamic version, despite the obscurity.
Contrary to most people on this forum my observation is that dynamic code is generally faster than static code.
One explanation I have is that reading the static program from disk is generally slower that executing dynamic code in memory.
In addition my theory is that executing "DEFINE TEMP-TABLE blabla" at run time, even though it is static code, still needs to create the structure in memory at run time, not at compile time.
So in execution time that is equivalent to "CREATE TEMP-TABLE".
Let's say both of these statements cost 1 ms.
If reading the static program from disk costs 5 ms the math is easy. You can avoid those 5 ms in the dynamic case.
my $ 0.02
-peter
In my case, this testing involves building a lot of temp-tables in objects, but the same code and with -q so there is no reading of code from the disk after the first one ... and the dynamic code needs to be read from disk too, anyway. My thought was that all the symbols one has to process with dynamic would slow it down ... but perhaps that isn't the case in the p-code.
tamhas wrote:
In my case, this testing involves building a lot of temp-tables in objects, but the same code and with -q so there is no reading of code from the disk after the first one ... and the dynamic code needs to be read from disk too, anyway. My thought was that all the symbols one has to process with dynamic would slow it down ... but perhaps that isn't the case in the p-code.
Mind you that -q still means that disk reads are done in order to verify that the code on disk has not changed!
You should not need to read the dynamic code from disk more than once.
-peter
Right, but the touch to see that nothing has changed has to be done by the dynamic code too. In fact, because of the more complex inheritance structure, the AETF code involves more files so that should be a bigger factor for it.
Looking more closely at the data this morning, it appears that the data are a bit more complicated than my quick glance last night. I ran two sets of tests. One was adding 5000 objects to a single temp-table and the other was adding 10 objects each to 1000 different temp-tables. In the first test, the static code performed better than the dynamic code using both 10.2B and 11.0Beta. Curiously, while the time for object creation was dramatically less in 11.0, the time for adding into collections actually went up although the total process ... object creation plus adding to the collections was a little faster.
In the second test, the static code was faster than the dynamic code in 10.2B, but slower in 11.0. Net for the total process was faster for dynamic, but not much changed for static.
So, I may just not have fine enough instruments...
Mind you that -q still means that disk reads are done in order to verify that the code on disk has not changed!
Peter, according to my experience and a quick validation in the documentation -q forces the AVM to NOT check if the file has modified on disk if the R-code still resides in memory.
I suppose this is easily checked with Process Monitor, but the documentation says:
Ordinarily in an ABL procedure, when the RUN statement is used to run a subprocedure, the AVM searches the directories named by the PROPATH environment variable, looking for a procedure of the same name with a .r extension. If it finds a file with a .r extension (an r-code file), it checks to make sure the r-code file has not changed since that r-code file was created.
This search is very useful in a development environment where procedures change regularly and you want to make sure you are always running the most current version of your application. However, in a production environment, you might want to bypass this search.
With Quick Request (-q), after the initial search, if the procedure still resides in memory or in the local session-compiled file, the AVM uses that version of the procedure rather than searching the directories again. However, the AVM always checks whether Data Dictionary definitions related to a procedure were modified. If they were modified, the AVM displays an error when it tries to retrieve the procedure.
That seems pretty clear that it won't check.
I thought that (not to check the r-code) was the whole point of -q .
you can force a re-read by CURRENT-LANGUAGE = CURRENT-LANGUAGE .
you can force a re-read by CURRENT-LANGUAGE = CURRENT-LANGUAGE .
Sopmehow I doubt that the Dr. would do that during his performance tests. What a fun discussion for a beer/red wine in Amsterdam.
mikefe wrote:
Mind you that -q still means that disk reads are done in order to verify that the code on disk has not changed!
Peter, according to my experience and a quick validation in the documentation -q forces the AVM to NOT check if the file has modified on disk if the R-code still resides in memory.
Oops yes of course you guys are right here.