Interpretor speed (was Re: Modifications to monitoring software)

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Thu Jan 10 2002 - 07:23:50 EST

  • Next message: Betty Mcbreen: "Fw: [Rhic-rcf-l] brahms users: rmine001 reboots today 1/24 2pm"

    Hi Kris et al, 
    
    On Wed, 09 Jan 2002 15:28:17 -0600 (CST)
    Kris Hagel <hagel@cyclotronmail.tamu.edu> wrote
    concerning "Modifications to monitoring software":
    > 2. Changed the calls to BrRawDataInput in BrBaseMonitor from using
    >    the root dictionary which was necessary in brat1 before brop was
    >    separated out to avoid cyclic dependencies to direct calls.  This
    >    cleans things up quite a bit and also improved the rate at which
    >    one can read events.  As it turned out, we were spending quite a
    >    bit of time in the root dictionary. 
    
    FYI, Depending on what you do, executing code via the interpretor
    (messages like TROOT::ProcessLine(const char*)) are executed an order
    or magnitude slower than the compile code.  This is because the
    interpretor has to look up the messages invovled in the execution, get
    pointers to various objects and arguments, and so on. 
    
    So, if possible, always try to use compiled code rather than
    interpreted.  
    
    So how come we use the interpretor in processing configurations
    scripts to bratmain?  Well, it's a speed-tradeoff for the increased
    flexibility that the configuration scripts provide.  However, since
    that interpretation is only done once, at the begining of the job, and
    the rest of the job is using compiled code, I felt that this was a
    minor nuacance. 
    
    If you really would like to have the configuration run as compiled, I
    suggest you make a script like 
    
      { 
        gSystem->Load("myconfig.so"); 
        myconfig();
      }
    
    The library myconfig.so should be generated from a source file that is
    like a regular configuration script, like 
    
      #ifndef __CINT__
      // All headers needed should go here
      #ifndef BRAT_BrAppOptionManager
      #include "BrAppOptionManager.h"
      #endif
      #ifndef BRAT_BrMainModule
      #include "BrMainModule.h"
      #endif
      #ifndef BRAT_BrMainDb
      #include "BrMainDb.h"
      #endif
      #endif 
    
      #ifndef __CINT__
      void myconfig()
      #endif 
      { 
        // ladida 
        ...
      }
    
    which you then can compile into a module with a Makefile.am like 
    
       pkglib_LTLIBRARIES	   = myconfig.la
       myconfig_la_SOURCES	   = myconfig.C 
       myconfig_la_LDFLAGS	   = -module -avoid-version 
    
    or via ROOT's AcLic
    
       root> .L myconfig.C+
    
    In this way, the configuration is executed as compiled code, but then
    you have to go through a compile cycle each time you change the
    configuration, and my guess is the time spending making myconfig.so is
    more or less the same it takes the interpretor to interpret the
    script, so I guess you don't gain much from this.  Anyway, now you
    know. 
    
    Yours, 
    
    Christian Holm Christensen -------------------------------------------
    Address: Sankt Hansgade 23, 1. th.           Phone:  (+45) 35 35 96 91 
             DK-2200 Copenhagen N                Cell:   (+45) 28 82 16 23
             Denmark                             Office: (+45) 353  25 305 
    Email:   cholm@nbi.dk                        Web:    www.nbi.dk/~cholm
    



    This archive was generated by hypermail 2b30 : Thu Jan 10 2002 - 07:24:54 EST