home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23772 < prev    next >
Encoding:
Text File  |  1993-01-12  |  3.4 KB  |  93 lines

  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  3. From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
  4. Subject: Re: A simple xload program using proc fs
  5. Message-ID: <1993Jan12.175521.3537@klaava.Helsinki.FI>
  6. Keywords: xload
  7. Organization: University of Helsinki
  8. References: <1993Jan12.125403.14817@olymp.informatik.uni-bonn.de>
  9. Date: Tue, 12 Jan 1993 17:55:21 GMT
  10. Lines: 81
  11.  
  12. This isn't really a comment on the xload program, but just a general
  13. warning about performance, as I've seen a couple of mails/postings
  14. saying that the /proc thing is slower than a kmem based 'ps' etc. 
  15.  
  16. While the /proc interface may not be the fastest possible, you can
  17. probably get much better perfomance by readin things in bigger chunks
  18. and only once.  I wrote the routines in such a way that they should work
  19. fine even if you do several small reads, but the whole buffer is always
  20. calculated for each read, so using stdio routines is generally not the
  21. best way to handle it (at the very least, stdio needs to do two reads:
  22. the second one will just return EOF). 
  23.  
  24. In the xload case this isn't really something you need to care about, as
  25. the buffer is both small and fast to calculate, and xload doesn't need
  26. to read it very often anyway, but this is also an easy way to show the
  27. "preferred" way of handling the /proc directory, so I'll use it as an
  28. example. 
  29.  
  30. In article <1993Jan12.125403.14817@olymp.informatik.uni-bonn.de> lederer@informatik.uni-bonn.de writes:
  31. >
  32. >void get_value(Widget w, XtPointer client_data, XtPointer chart_value)
  33. >{
  34. >    FILE *loadavg;
  35. >    
  36. >    if( (loadavg=fopen(LOADAVG,"r"))==NULL)
  37. >        {
  38. >            fprintf(stderr,"couldn't open %s",LOADAVG);
  39. >            exit(1);    
  40. >        }
  41. >    fscanf(loadavg,"%lf", (double *) chart_value);
  42. >    fclose(loadavg);
  43. >}
  44.  
  45. The optimal way to do this is probably:
  46.  
  47. void get_value(Widget w, XtPointer client_data, XtPointer chart_value)
  48. {
  49.     static int fd = -1;
  50.     static char buf[4097];
  51.     int i;
  52.  
  53.     *(double *) chart_value = 0.0;
  54.     if (fd < 0) {
  55.         fd = open(LOADAVG,O_RDONLY);
  56.         if (fd < 0) {
  57.             fprintf(stderr,"couldn't open %s\n",LOADAVG);
  58.             exit(1);
  59.         }
  60.     }
  61.     i = read(fd,buf,4096);
  62.     if (i > 0) {
  63.         buf[i] = '\0';
  64.         sscanf(buf,"%lf", (double *) chart_value);
  65.     }
  66. }
  67.  
  68. A couple of points:
  69.  
  70.  - do the open only once if at all possible, as you'll otherwise have to
  71.    look up the name every time.  If you have to open several different
  72.    /proc files, and not much else, the fastest way is to do a "chdir()"
  73.    to the /proc directory, and then use relative filenames.  This way
  74.    you avoid looking up the inodes etc from disk, and can do name lookup
  75.    entirely in the procfs (this probably only pays off with 'ps', and
  76.    maybe not even there..).
  77.  
  78.  - read all the statistics files (/proc/loadavg, /proc/meminfo,
  79.    /proc/<pid>/stat etc) with just one read, with a buffer of 4096
  80.    bytes.  Also note that the strings are usually not '\0'-terminated,
  81.    so you have to do that yourself with the value returned by the read
  82.    if you are going to use them as strings.  This means that the buffer
  83.    actually has to be 1 byte longer than a page for safety (but note the
  84.    special meaning of '\0' in /proc/xxx/environ and /proc/xxx/cmdline)
  85.  
  86.  - these points are meaningless unless you really care about
  87.    performance: all the /proc files have been designed so that you can
  88.    use shell scripts, perl or whatever to read and parse them.  So use
  89.    perl/shell scripts (or stdio) when appropriate, and try to optimize
  90.    only when there is any reason for it. 
  91.  
  92.         Linus
  93.