Trigger Improvements

["Smith, Nelson" <NSmith@xxxxxxxxxxx>]

One of our programmers has been working on improvements to our Trigger
programs and has come up with some puzzling results.  

Originally, most of our triggers just assigned unique keys and that was
about it.  However, over the years, many more functions have been added to
them such as updating other files, etc.  Many of these newer functions don't
directly change the file actually being triggered and it was felt that if
those functions could be moved out of the trigger program itself, the
trigger would run much faster.

So the functions that were not needed directly in the trigger program were
replaced by a message sent to a dataq which contained the entire trigger
buffer.  Then a never-ending program watched the dataq for incoming messages
and called another program to perform those functions in a batch job. 

The process works great and testing shows that the trigger consistently runs
about 3 times faster when a large number of records are updated in a loop.
i.e. 60,000 records updated in about 3 minutes vs. about 10 minutes using
the original trigger.  The puzzling thing is that when he tests the new vs.
the old triggers in a long-running batch night job (our main billing run)
the results are reversed.  The nightly batch job runs longer with the new
trigger.  The environment is kept the same and all files are restored to
original prior to each test run and no one else is on the system at the time
(this is on our development system). 

The only difference I can see is that his earlier tests involved updating a
lot of records in a tight loop, whereas the nightly batch run updates the
same records from many different programs at many different points in the
run.  Is there any kind of initial overhead involved with "opening" a dataq
for the first message, that would show up when randomly sending it messages
that would not be significant when messages are sent in a tight loop?  In
the tight loop, the trigger program and the dataq are probably retained in
memory whereas they might get swapped out in the batch job between messages.
Would this be significant enough to make that much difference? 

Any other suggestions at to what the difference might be?


Nelson Smith
nsmith@xxxxxxxxxxx
ncsmith@xxxxxxxxxxxxxxx



************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which may be confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message. 
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer. 
If you received this message in error, please notify us immediately at 
MailAdmin@xxxxxxxxxxx or (800) 284-2006.
************************************************************************************************************************************************************************************************************