SCons Node.FS.Base _get_str method appears to cause a lot of calls to os.stat

"Tom Tanner (BLOOMBERG/ LONDON)" <ttanner2-AlFclGv/[email protected]>
Newsgroups gmane.comp.programming.tools.scons.devel
Message-ID <57EBAC1301FC0352003902CF_0_42974@msclnjpmsgsv01>
This:
 
 702 -    def _get_str(self): 
 703          global Save_Strings 
 704          if self.duplicate or self.is_derived(): 
 705              return self.get_path() 
 706          srcnode = self.srcnode() 
 707          if srcnode.stat() is None and self.stat() is not None: 
 708              result = self.get_path() 
 709          else: 
 710              result = srcnode.get_path() 
 711          if not Save_Strings: 
 712              # We're not at the point where we're saving the string 
 713              # representations of FS Nodes (because we haven't finished 
 714              # reading the SConscript files and need to have str() return 
 715              # things relative to them).  That also means we can't yet 
 716              # cache values returned (or not returned) by stat(), since 
 717              # Python code in the SConscript files might still create 
 718              # or otherwise affect the on-disk file.  So get rid of the 
 719              # values that the underlying stat() method saved. 
 720              try: del self._memo['stat'] 
 721              except KeyError: pass 
 722              if self is not srcnode: 
 723                  try: del srcnode._memo['stat'] 
 724                  except KeyError: pass 
 725          return result 
 726   

appears to be responsible for a huge number of stat calls in our build. I'm a little confused as I don't see why the file *name* should change as the result of Python code in the SConscript files. Shouldn't it be calling self.exists or self.rexists (admittedly I'm not sure which one right now).

_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.