David If you look at the MAP command, globally cataloged programs keep track of the number of times they have been run since being cataloged. That suggests that their headers are updated when they are called, which would explain why they are slower.
Normally UniVerse cached subroutine object in memory for efficiency until you return to TCL. But I really don't understand why a function is slower. Are you actually using a FUNCTION or a DEFFUN ...CALLING construct? Brian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > David Wolverton > Sent: 15 March 2007 17:50 > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] [UD] CALL @progname > > Actually - I just ran a test, and was surprised somewhat: > > 1,000,000 Iterations of ways to do a call... > > CALL PROGNAME (direct) 7047 > CALL *PROGNAME (global) 7766 > CALL @PROGNAME (indirect) 6984 > GOSUB (logic contained in-line) 1531 > Call as Function 10203 > > I've rearranged the order the routines are called in, and run > the test suite over and over... The Indirect calls are > CLEARLY faster, with all numbers moving +/- 50, EXCEPT the > indirect, which only moved +/- 25 or so. > > Note that I set the @PROGNAME outside of the "call" loop - > this was not testing how fast the system could set variables > - just the difference on the 'calls'. If I include the > setting of the name WITHIN the loop, the indirect call went > to 7290 or so -- the difference in the 'direct' call vs the > 'indirect' call efficiency appears to be in the Variable > handling! But both are still faster than use of Global catalogs. > > Anyone have a clue why the indirects are a hair faster? Or am > I just getting lucky over and over? I always thought they > were slower as well! > > DW > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > David Murray > > Sent: Thursday, March 15, 2007 11:32 AM > > To: u2-users@listserver.u2ug.org > > Subject: RE: [U2] [UD] CALL @progname > > > > David, > > > > @CALL's are very inefficient and slow. It would be worth > doing a speed > > test.> > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
