home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / bit / listserv / sasl / 5745 < prev    next >
Encoding:
Text File  |  1993-01-25  |  4.3 KB  |  124 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!udel!darwin.sura.net!paladin.american.edu!auvm!UNC.BITNET!UNCSM1
  3. Return-Path: <@OHSTVMA.ACS.OHIO-STATE.EDU:SAS-L@VTVM2.BITNET>
  4. Message-ID: <SAS-L%93012509284375@VTVM2.CC.VT.EDU>
  5. Newsgroups: bit.listserv.sas-l
  6. Date:         Mon, 25 Jan 1993 09:29:00 EST
  7. Reply-To:     Sally Muller <UNCSM1@UNC.BITNET>
  8. Sender:       "SAS(r) Discussion" <SAS-L@UGA.BITNET>
  9. From:         Sally Muller <UNCSM1@UNC.BITNET>
  10. Subject:      re: Saving time with indices....
  11. Lines: 111
  12.  
  13. ----------------------------------------------------------------------
  14. SUMMARY:  Word from high regarding Simon Dunkley's posting on
  15.           "saving time with indices."
  16. E-ADDR:   uncsm1@unc.bitnet
  17. NAME:     Sally Muller
  18. PH/ADDR:  919-962-6501  OIT CB#3455, UNC, Chapel Hill NC 27514
  19. ----------------------------------------------------------------------
  20. As you all know SAS Institute has a strict policy about its employees
  21. replying to news groups.  However, I occassionally get something to
  22. share with y'all.....
  23.  
  24. ==========================begin SAS-L message===========================
  25.  
  26. > In article <199301221112.AA08459@lamb.sas.com>,
  27. >  sdd@leicester.ac.uk (Simon Dunkley) writes:
  28. >>
  29. >> I have a large dataset (76,000 obs, 8 vars = 5.6Mb) that I
  30. >> needed to do a many to one linkage from a small dataset (900
  31. >> obs, 2 vars) When I came across the 'create index' thing (new)
  32. >> in 'proc datasets' I thought that this might be a more
  33. >> economical way of doing the linkage rather than using 'proc
  34. >> sort' on both files.  I was expecting that 'proc sort' and
  35. >> 'create index' would take about the same cpu time and the
  36. >> 'merge' would take slightly longer.  The saving being that I
  37. >> do not need the disk space to hold the sorted verions of the
  38. >> datasets. The index (a character string) takes only 75K.
  39. >>
  40. >> Because the one dataset is tiny compared with the other I
  41. >> decided to see what the timing differences were whith the
  42. >> various combinations of sorting and indexing.
  43. >>
  44. >>         order           order   merge
  45. >> Big     time    Tiny    time    time
  46. >> sort    12.6    sort    0.25    10.58
  47. >> sort    12.6    index   0.57    11.89
  48. >> index   22.6    sort    0.25    50.03
  49. >> index   22.6    index   0.57    50.7
  50. >>
  51. >> I really didn't expect the difference to be five fold on the
  52. >> merge, or three times overall.  ]
  53.  
  54. -----------------------------------------
  55. >
  56. > The data step merge program is not listed here, but I suspect
  57. > that it looked something like this:
  58. >
  59. >  data new;
  60. >       merge large(in=large)
  61. >             small(in=small);
  62. >       by idvar;
  63. >       if large and small;
  64. >
  65. > The developer creates an index on the "idvar" variable in the
  66. > dataset named "large".  The expectation is that the SAS system
  67. > will use the index to quickly retrieve the subset of records in
  68. > "large" that have a matching value for "idvar" in small.
  69. > Unfortunately the index can only be used in this example to
  70. > surface the observations in "large" in ascending "idvar" order.
  71. > The index cannot be used to do the subsetting.
  72. >
  73. > If you converted this data step to an sql join then the indexes
  74. > would produce a performance gain.  To rewrite the merge as an SQL
  75. > join:
  76. >
  77. >   proc sql;
  78. >        create table new as
  79. >        select * from
  80. >        small as i, large as j
  81. >        where i.idvar = j.idvar;
  82. >
  83. >
  84. > This example was lifted from a paper by Beatrous in the SUGI 16
  85.   (ed. note                                                  )
  86. > procedings pp 605-614.  You may want to get a copy of this paper
  87. > as a guide to effective use of indexes.  In the paper, the
  88. > following CPU results were reported:
  89. >
  90. >                     CPU       CPU
  91. >                   Without     With
  92. >   Method          Indexes     Indexes
  93. >   =====================================
  94. >   data step
  95. >   merge              16        26
  96. >
  97. >   SQL Join           23         0.3
  98. >
  99. > Adding indexes and converting the application from a data
  100. > step merge to an sql join took the cpu performance from 16
  101. > seconds to .3 seconds.  Not bad.
  102.  
  103. ==========================end SAS-L message===========================
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118. --
  119. Stephen Beatrous              "Can we buy a hooker?"  "What?!"
  120. sassmb@unx.sas.com            "A hooker, the thing on the back of a
  121. (919)677-8000 x7662            car that pulls a boat."
  122.                               A conversation between Lee(5) and his
  123.                                 Dad(a lot older than 5)
  124.