Hi
It has been my experience that if I have a query so do plenty of others so I
post this for those who do not automatically optimise their code. Perhaps
they were scared off it originally as I was.
Tony's blog approaches it from a different tack and I see no obvious
variances other than one small item. Optimise is no longer supported on
compiling terminal definitions on Windows. Those on Linux can check for
their version. A small note on that point. We deliberately slowed down
terminal display by breaking up the CRT commands into individual lines
because this saved us having to set different time delays for the sundry
terminals that people had. I intend to go to the one big line at the
generate stage for our next version as advised in the manual since those
slow terminals have no doubt passed on to the big trash pile for future
generations to clean up.
I delayed posting until I had an answer from TData/TigerLogic re the system
halt now Action Item 33973 easily avoided but a pain if caught.
D3 Windows FlashBasic Optimise
Question 1
Will you notice any appreciable difference on a typical Basic data entry
program on a typical 5-10 user site?
No
Question 2
What is the advantage?
Massively improved string handling on large items. The conversion of a 2Mb
item from Windows/Unix text to a pick item is in the order of 100 times
faster.
Improved speed on loading of small subroutines handling long strings as
experienced with Javascript Ajax calls.
Question 3
What tests did I do?
Convert of a 2Mb file containing in excess of 10,000 records/items. Basic 1
minute 6 seconds, optimised FlashBasic under 1 second.
Reprice 10,500 credit card transactions hitting a dozen files,creating a
temporary summary file and a print of the summary file. Flashbasic 35
seconds, Basic 89 seconds. the source records are small whereas the most
common price record I had allowed to be 120Kb in 39 multi-valued attributes.
All reads are Matreads.
The machine is a 4 year old XP so no warp speed here.
Question 4
Are there any advantages on reads and writes?
NO. I initially thought that perhaps Matreads would show an optimised
advantage however when thinking it through I realised that they are of
course low level items that are undoubtedly already in optimal form. I
tested both Matread and Read with Parse to a known array size. I had to run
through 50,000 records varying in size from 120Kb to 5Kb to even get a
timimg around 20 seconds with a slight tilt of a second or so to the
Flashbasic routine.
Question 5
Are there any "gotchas".
Yes.
Debug facilities are reduced.
A CALL mistake can cause a system halt requiring a shutdown and restart.
All programs must be flashed or none if you use Named Common.
Bounds checking has to be turned on as it is off by default in levels 1 and
up. It appears that the levels above 0 may no longer be available so this
not an issue any more.
Question 6
How does one implement it?
Step 1
Make a list of every program and check if you have the source code.
Step 2
Decatalog all of them but only from the md if you do not have the source.
The w option is not much use if you just decataloged the object ;-)
If you use CALL @VAR and accidentally call a program that has been
catalogued without optimise from an optimised routine you will cause a
system halt. Depending on your luck this may recover but mostly it wrecks
the logon. You can logoff but you cannot get back on. I always test with
at least two windows open so I was able to go to the other one and do a
shutdown.
Step 3
Change the COMPILE verb in this account to always optimise
Step 4
Recompile and recatalog all programs.
Step 5
Ensure that you cannot accidentally share or release compiled programs from
a non optimised source. Do not forget to Compile and optimise all the
emulation routines such as Hostaccess or Accuterm. This is not a problem as
they will drop back a level to Basic if they are run from a non optimised
routine such as you may have set up in a test account to get the full value
of Debug.
Peter McMurray
.
|
